test(senpi-task): prove the auto-deny reaches the host before the next command

[code-yeongyu]

Summary

Replaces the wall-clock assertion in the HostSessionClient confirm auto-deny test, which went red on a loaded Windows runner (run 36309221289, 55.2 ms > 50 ms) while the deny frame was correct.

Root cause

A test flake, not a product bug. session-client.ts dispatches the deny (void sendExtensionUIResponse(...)) synchronously on ingest, with no timer on the path. The test measured socket round-trip latency against a fixed 50 ms budget.

Fix

The test now asserts the contract the product guarantees. The host sends the UI request followed by an agent_end record on the same stream, and the test awaits the client forwarding that event, which proves the request was already ingested. Then it issues getState(). The host's command log must show extension_ui_response before get_state, with the deny payload confirmed: false. No sleeps, no timing budget.

QA & Evidence

• bun test packages/senpi-task/src/runners/rpc-host/session-client-records.test.ts: 8 pass. --rerun-each 50: 400 pass, 0 fail. tsgo -p packages/senpi-task and biome are clean.
• Mutation: making the product's deny wait 8 s before sending turns the new test red in 4 ms (get_state arrives first). The previous version of this change still passed under the same mutation, which is why the ordering assertion replaced it.
• Test-only change; product code is unchanged, so no live Senpi driver run applies.
• Windows focused soaks (3 x 10 iterations) are listed in a comment.

Fixes #8950
Refs #8324

---

Summary by cubic

Replaces the flaky confirm auto-deny test in HostSessionClient records, which timed out at 50 ms on a loaded Windows runner (55.2 ms) even though the deny payload was correct. The new test proves the deny reaches the host before the client's next command, instead of measuring socket latency.

• Awaits the client forwarding the agent_end record (confirming the UI request was already ingested), then asserts extension_ui_response appears before get_state in the host's command log.
• Test-only change; verified with --rerun-each 50 (400/400 pass) and a mutation delaying the deny by 8 s, which the new test catches in 4 ms.

Fixes #8950

^{Written for commit 32df0e9. Summary will update on new commits.}

[code-yeongyu]

Focused Windows soaks (windows-latest, 10 iterations each): 36324960795 success, 36324963152 success, 36324966543 success.

[code-yeongyu]

Another occurrence this PR fixes: soak run 36353556711 (from another session's Windows shard-2 soak) failed on exactly this assertion, session-client-records.test.ts:55 expect(elapsedMs).toBeLessThan(50), with 119.7 ms received. This PR replaces the wall-clock budget with an ordering proof: the deny reaches the host before the client's next command (get_state), after the record that follows the request has been ingested. That behavior is timing-independent.

[code-yeongyu]

Superseded by #8961, which lands this fix together with the other win-ci fixes as one merge (all commits of this branch kept, bundles regenerated once over the merged sources). The evidence in this PR (RED/GREEN, focused Windows soaks) still applies; the issue is closed by #8961's Fixes line.