feat(workhub): project delegated execution status

[ARE404]

Summary

Deliver Slice 5-B execution feedback on top of the durable delegation linkage from #3935:

• acknowledge the atomic delegation_assigned record immediately as accepted
• project accepted, running, waiting, completed, failed, aborted, and recovering from the exact target Session/Turn
• refresh from Session change notifications with generation fencing so stale reads cannot overwrite newer state
• rebuild the projection after navigation or restart without persisting a second WorkHub lifecycle
• preserve the preassigned WorkHub root identity through idle recovery while keeping ordinary queued successors on fresh identities
• make the projected delegation result navigate to its authoritative target Session

The target ordinary Session remains the only execution authority. This PR does not add replace, Stop ownership, supersession, or destructive correction.

Refs #3492
Proposal: #3286

Design choice: hybrid first response

The durable assignment is the immediate acknowledgement; WorkHub does not wait for target completion before confirming acceptance. It then joins the immutable delegation link to the exact target Turn and Session live state. Terminal Turn facts win, exact live membership projects running/waiting, unreadable authority projects recovering, and a not-yet-observed Turn remains accepted.

Execution status stays a rebuildable read model. Session change notifications invalidate it, opening WorkHub reconstructs it, and a generation fence drops stale asynchronous reads. No mutable coordination-status record or second recovery state machine is introduced.

Runtime recovery preserves a preassigned future root identity only for current-Turn steering admissions. Ordinary next-Turn follow-ups carry their predecessor identity, so they continue to receive a fresh successor rather than becoming self-referential.

Verification

• npm run lint — PASS
• npm run format:check — PASS
• npm run build — PASS
• npm run typecheck — PASS
• npx knip --workspace apps/desktop — PASS
• npx knip --workspace packages/ui — PASS
• npm --workspace @maka/runtime-host test — PASS (1357 tests; 1348 passed, 9 skipped, 0 failed)
• npm --workspace @maka/desktop test — PASS (1644/1644)
• WorkHub Electron E2E — PASS (2/2):
  • WorkHub rebuilds delegated execution feedback after navigating away and back
  • WorkHub defers destructive correction until linked delegation exists
• git diff --check upstream/main..HEAD — PASS

The WorkHub Electron E2E output is the user-visible behavior evidence for this change. It exercises delegation feedback reconstruction after leaving and reopening WorkHub.

Exact verified head: 179ba06afbf05d0648c400f7bd17a12cbc031af3.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Codex implemented the production and test changes, updated the ADR, investigated identity recovery behavior, and ran the listed verification. The commit includes the required Generated-by: Codex trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[M4n5ter]

English

Reviewed at exact head 179ba06afbf05d0648c400f7bd17a12cbc031af3.

Blocking concern: the projection follows the admission Turn, not the delegated Message

The durable assignment records targetTurnId from the target's root state at admission time. The new projection then reads the lifecycle of exactly that Turn.

However, the existing Message authority explicitly allows an unconsumed steering Message to be folded into the follow-up queue when its original Turn ends, then executed by a fresh successor Turn. This is already covered by the existing “lone folded steering entry” regression test.

A supported path is therefore:

1. WorkHub delegates to active Turn A and persists targetTurnId = A.
2. Turn A finishes before consuming the steering Message.
3. The Message is folded into successor Turn B.
4. Turn A records completed.
5. Turn B is still running, waiting, or may later fail.
6. WorkHub projects Turn A and reports the delegation as completed.

The displayed lifecycle would describe the admission Turn, not the execution of the delegated work. The same mismatch would make future linked correction or Stop ownership target the wrong Turn.

The recovery change exposes the same underlying issue for concurrent pending admissions: if multiple pending steering admissions carry different preassigned identities, sharedPendingRootIdentity returns undefined and recovery aggregates them under a newly generated Turn. Their immutable targetTurnId links then no longer identify the actual execution.

Suggested direction

The stable identity of a delegation should be the target Message, not its initial Turn.

delegation_assigned already persists targetMessageId. I suggest resolving that Message through the target Message authority—pending admission, immutable steering proof, and root source receipt—to find its current or terminal owning Turn, then projecting that Turn's lifecycle.

In that model:

• targetTurnId may remain the admission location, but is not treated as immutable execution ownership;
• steering rollover and recovery remain valid Runtime behavior;
• concurrent Messages may correctly resolve to the same aggregated successor Turn;
• future correction/Stop can bind to the Turn that actually executes the delegated Message.

Alternatively, if the product contract requires one immutable target Turn, admission must guarantee that the delegated Message can never migrate to a successor. Preserving selected root identities only during one recovery path is not sufficient.

The hybrid acknowledgement, rebuildable projection, generation fence, and UI navigation all look reasonable, but I think this identity boundary needs to be corrected before the execution-status contract is reliable.

简体中文

审查的精确 head 为 179ba06afbf05d0648c400f7bd17a12cbc031af3。

阻塞问题：投影跟随的是 admission Turn，而不是被委托的 Message

持久 assignment 会记录 admission 时目标 root state 中的 targetTurnId，新的 projection 随后读取这个确切 Turn 的生命周期。

但现有 Message authority 明确允许尚未被消费的 steering Message 在原 Turn 结束时折叠到 follow-up queue，并由新的 successor Turn 执行。仓库现有的 “lone folded steering entry” 回归测试也确认了这是正式支持的行为。

因此存在以下受支持路径：

1. WorkHub 将任务委托给正在运行的 Turn A，并持久化 targetTurnId = A。
2. Turn A 在消费该 steering Message 之前结束。
3. Message 被折叠到 successor Turn B。
4. Turn A 记录为 completed。
5. Turn B 仍在运行、等待用户，或者之后执行失败。
6. WorkHub 投影 Turn A，并把这次 delegation 显示为已完成。

此时界面展示的是 admission Turn 的生命周期，而不是被委托工作的实际执行状态。未来实现 linked correction 或 Stop ownership 时，同样可能控制错误的 Turn。

并发 pending admission 的恢复也暴露了相同根因：当多个 pending steering admission 携带不同的预分配 identity 时，sharedPendingRootIdentity 会返回 undefined，恢复逻辑将它们聚合到一个新生成的 Turn。原有不可变 targetTurnId 链接随后都不再指向实际执行。

建议方向

delegation 的稳定身份应该是目标 Message，而不是它最初进入的 Turn。

delegation_assigned 已经持久化了 targetMessageId。建议通过目标 Message authority——pending admission、immutable steering proof 和 root source receipt——解析该 Message 当前或最终归属的 Turn，再投影这个 Turn 的生命周期。

在这个模型中：

• targetTurnId 可以继续表示 admission location，但不再被视为不可变的 execution ownership；
• steering rollover 和 recovery 仍然是合法的 Runtime 行为；
• 多个并发 Message 可以正确解析到同一个聚合后的 successor Turn；
• 未来 correction/Stop 可以绑定真正执行该 delegation 的 Turn。

另一种选择是：如果产品契约要求目标 Turn 永远不可变，那么 admission 必须保证 delegated Message 永远不会迁移到 successor。只在某一条 recovery 路径中保留预选 root identity，并不足以建立这个保证。

Hybrid acknowledgement、可重建 projection、generation fence 和 UI navigation 本身都比较合理，但在 execution-status contract 可靠之前，我认为需要先修正这个 identity 边界。