buzz-agent can acknowledge a steer that is dropped during turn completion

[stevelr]

I can easily reproduce the failure. codex gpt-5.6-sol wrote the diagnosis (quoted below)
Found while trying to reproduce 4939

Describe the bug

buzz-agent intermittently acknowledges a steer successfully but completes the
active turn without sending the steered content to the provider.

The existing steer_folds_into_active_turn_without_cancelling test exposes this
as:

steered text never reached the provider

The steer handler considers the request accepted when tx.send(p.prompt) succeeds
and immediately returns { runId, messageId }. However, RunCtx::run drains the
steer queue only at the beginning of each round. A steer queued after the final
drain but before the outer prompt task clears active_run_id and steer_tx can
therefore be acknowledged and then dropped when the turn ends.

To reproduce

  for i in {1..20}; do
    echo "attempt $i"
    cargo test --release -p buzz-agent --test fake_llm
  done

Look for:

steer_folds_into_active_turn_without_cancelling ... FAILED
steered text never reached the provider

It does not reproduce when running test steer_folds_into_active_turn_without_cancelling in isolation (passed 10/10 times).

Expected behavior

a successful steer response guarantees that the active run
consumes the steer. If the run is already finishing, the request should be
rejected so the client can fall back to starting another turn.

Suggested direction

coordinate turn closure with steer acceptance, or attach a
consumption acknowledgement to queued steers and return success only after the
active run has incorporated the message. Before returning end_turn, the run
should stop accepting new steers atomically and process any already accepted
messages.

Additional Info

got-5.6-sol says it's 95% confident this is a real implementation bug:

Evidence:

• The handler returned a successful steer response with the expected runId.
• The prompt completed normally.
• Captured provider requests never contained the steered text.
• The behavior occurred twice in ten full package-test runs.
• The code has a clear window between the final drain_steers() and clearing
  steer_tx.

I’m about 85–90% confident in the precise root-cause explanation without adding
tracing. Another synchronization path could contribute, but a successful
acknowledgement followed by lost valid input contradicts both the test and the
handler’s documented behavior.

[iroiro147]

Confirmed the race you're describing — run_prompt acknowledges a steer as long as steer_tx.send() succeeds, but drain_steers() only lives at the start of each provider round. If the last drain already ran and the turn is tearing down, the message is accepted and then dropped when cleanup clears steer_tx and saves history.

PR #5069 fixes it: after the session stops accepting new steers it does a final drain into history before saving, so an acknowledged steer surfaces as the next turn's first user message (with a WARN when the race fires). Deterministic regression test in the PR covers both the fold-into-live-turn and fold-into-next-turn paths.