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

I can easily reproduce the failure. codex gpt-5.6-sol wrote the diagnosis (quoted below)
Found while trying to reproduce [4939](https://github.com/block/buzz/issues/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.

Start with the steer_folds_into_active_turn_without_cancelling test and the cargo test --release -p buzz-agent --test fake_llm reproduction. Inspect the steer handler and RunCtx::run around steer draining and turn closure. Done means an accepted steer is consumed by the active run, or a steer arriving during closure is rejected so the client can retry, with the regression test passing repeatedly.

Written by the indexing model from the issue text.