prompt_async into a tool-executing turn aborts it and strands the new prompt

Observed

A prompt_async delivered while the session's turn is executing a tool aborts the in-flight turn and drops the new prompt: the session dead-ends (user message present, no assistant reply, no new run). The same prompt delivered during the reasoning phase merges cleanly and is answered.

Repro (opencode 1.18.x, build agent)

1. Dispatch a prompt whose first action is a long tool call (e.g. sleep 180 via bash).
2. ~1 min later, while the tool is still executing, POST /session/:id/prompt_async a short follow-up.
3. Sometimes: in-flight run aborted (MessageAbortedError-class kill, tool killed "User aborted the command") and the follow-up is never answered. Other times: the follow-up waits and is answered right after the tool finishes.

Race note

Observed tally across 5 certified mid-tool steers: abort+strand 1 / clean merge 4 (bash abort once; bash merge twice; MCP-tool merge twice). Timing/phase-dependent (step-boundary race), not tool-kind deterministic. A clean merge does not mean the path is fixed.

Expected

At minimum the steered prompt must start its turn (never silently dropped); ideally the abort card should not read as an error when the steer itself is the interrupter, or the dispatch should hold until the step boundary.

Context

Split out of openchamber/openchamber#3370 (defect 2), where the OpenChamber-side queue/steer defects are tracked separately. Happy to provide transcript timestamps on request.