feat(runtime-host): run queued next-turn messages as separate turns

[me2seeks]

Problem

While a root Turn is running, clients can submit multiple messages with placement: next_turn. Runtime Host currently aggregates every queued follow-up into one successor Turn.

Each send is an independently admitted user intent, but aggregation removes its individual Turn lifecycle. The messages share one response, failure outcome, retry boundary, and execution state. Interleaved steering and follow-up messages are also grouped by queue lane rather than preserved as separate future Turns.

This is distinct from #3538, which improves how Queue is reached and explicitly keeps delivery semantics unchanged.

Desired outcome

Treat each admitted next_turn message as one future root Turn:

• preserve FIFO order within the next-Turn queue;
• dequeue only one message when the active root Turn settles;
• give every queued message its own Turn, Run, response, failure, and retry lifecycle;
• keep Runtime Host as the sole queue and successor-Turn authority;
• preserve durable admission, recovery, cancellation, retraction, and multi-client guarantees;
• leave current_turn steering semantics unchanged.

For example, submitting A, B, and C with placement: next_turn should produce:

current Turn → Turn A → Turn B → Turn C

rather than one successor Turn containing A\n\nB\n\nC.

Alternatives or workarounds

The current implementation aggregates all pending follow-ups into one successor Turn. Users can retract the queue and manually resend each message after the previous Turn completes, but that defeats the purpose of queueing independent future work.

An explicit “append to queued draft” operation could still aggregate content when requested, but repeated send actions should retain independent Turn lifecycles.

Implementation should account for the durable message-lifecycle work in #3633 and queued Skill outcome work in #4054 before opening a PR.

Investigated with OpenAI Codex assistance.

[me2seeks]

take