feat(runtime-host): separate queued successor turns

[me2seeks]

Summary

• run each accepted next_turn message as its own FIFO successor Turn
• keep unconsumed steering messages together ahead of explicit successor work
• preserve queued messages across successor transitions and Runtime Host recovery
• apply the same per-successor capacity contract to submit, update, and promote operations

Fixes #4129

Verification

• npm run lint
• npm run format:check
• npm --workspace @maka/runtime-host run typecheck
• npm --workspace @maka/runtime-host run build
• 133 affected Runtime Host tests passed with a worktree-local TMPDIR

Full-workspace npm run typecheck reaches and passes Runtime Host, but currently fails in unrelated UI/Desktop files due to existing interface/build-output mismatches.

Review

Two independent reviews covered lifecycle/recovery correctness and design/simplicity. Both reviewers reported no blocking findings after fixes and re-review.

AI use

Select exactly one:

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

Tool(s) and scope: OpenAI Codex assisted with code investigation, implementation, tests, and review preparation.

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

[Astro-Han]

Thanks for separating explicit next-turn messages into distinct successor Turns. That matches the user-visible queue semantics better than aggregating unrelated future messages, and the normal FIFO and capacity paths look coherent.

I left one inline P2 on recovery identity. After a restart, the remaining queued admissions retain their original identity in durable storage, while their restored in-memory entries are rewritten to the active successor identity. Editing or promoting one of those entries then fails with an identity conflict. The queue remains durable and the failure is recoverable, so I do not think this rises to P1, but preserving the original admission identity would make the recovery path consistent.

Reviewed with Codex and two independent @Reviewer agents. I verified the exact head, queue and successor state transitions, durable admission identity, restart behavior, and passing CI.

中文对照

谢谢你把明确的 next-turn 消息拆成各自独立的 successor Turn。与把无关的未来消息聚合到一起相比，这更符合用户看到的队列语义，正常路径下的 FIFO 和容量判断也基本自洽。

我在恢复身份边界留了一条 P2 行内评论。重启后，剩余队列项在持久化存储中仍保留原始身份，但恢复出的内存 entry 被改写成当前 successor 的身份，因此编辑或 promote 这些队列项时会发生身份冲突。队列本身仍然持久化，而且这个失败可以恢复，所以我认为它不到 P1；不过保留原始 admission identity 会让恢复路径保持一致。

本次审查使用了 Codex 和两个独立的 @Reviewer 子代理；我核对了精确 head、队列与 successor 状态转换、持久化 admission 身份、重启行为和 CI 结果。

[Astro-Han]

[P2] Preserve each queued admission’s durable identity during recovery

These remaining admissions are still stored with their original turnId and runId, but this restores their LiveEntry objects using the newly active successor’s identity. A later queue.entry.update or queue.entry.promote therefore sends the rewritten identity to updateMessageAdmission(), where the durable store rejects it as an identity conflict.

This is reachable after a restart with two queued next-turn messages: the first becomes the recovered successor, while editing or promoting the second fails. Keeping admission.turnId / admission.runId here would preserve the admission provenance; reservedRoot already owns the active-root identity. A recovery regression that performs an update or promotion on the remaining entry would cover the composition boundary.