openshell lane: the copy-mode "mid-run second" steering assertion races the run's end #725

What happens

the openshell venue holds its declarations fails intermittently on the copy-mode steering case in .github/scripts/openshell-conformance.mjs:

FAIL    steering over the exec's stdin: exit 2 cost-cap (verified), runner delivered 1, acks verified over stderr 1, exit line names the first true, inbox says delivered; the mid-run second: queued (1 frames written, 2 wanted); marks [["queued","written"],["written|queued|withdrawn","delivered"],["written|queued|withdrawn","delivered"]], broken or refused false

Seen on the #723 rerun and on #724, on 2026-10-21. main passed the lane both before and after.

Why

The case runs with maxCostMicros: 0, so the runner exits at its cost cap almost immediately.

The second message is queued from inside the first markState(... "delivered"), and the relay writes it on a tick (void relayRef?.tick()). When the run ends before that tick writes the frame, the second message stays queued and only one frame is written.

That is a truthful outcome: the run ended, so nothing was written and nothing claims delivery. But the assertion requires written >= 2 and a second outcome of written or delivered.

Proposed fix

Two ways:

• Give the run room. Keep it alive long enough for the mid-run write, for example by sending a prompt that makes the runner do some work before the cap, or by delaying the cap.
• Accept the honest outcome and also prove the write. Treat queued with written === 1 and no false claim as an honest result, and prove the mid-run write in a separate case that does not end at the cap.

This lane must be stable before it becomes required (CLAUDE.md: "It becomes required in a later issue once it has passed across a round").