web: stream freezes after sending a steer message while a subagent is running

Summary

In the web UI, the live stream of a running session freezes (stops rendering new events) when a steer (插队) message is sent while a background subagent is running in the same session.

Steps to reproduce

1. Start a session in the web UI and give it a task that spawns a subagent (Background Agent still running).
2. While both the main turn and the subagent are active, send a steer message from the composer.
3. The transcript stops updating: the page itself stays interactive (scrolling/clicking works), but no new events render for the current session.
4. Switch to another session and switch back — rendering recovers immediately.

Reproducible consistently on this setup.

Expected behavior

The stream keeps rendering after a steer message regardless of subagent activity.

Analysis

• The backend is fine: server logs show no errors during the freeze, and switching sessions (which re-fetches/re-subscribes) restores rendering. So this looks like a frontend stream/state desync when a steer event interleaves with subagent task events — likely the session's stream subscription or working-state machine drops the turn without an error surface.
• Possibly related to past fixes in the same area: "Fix sessions getting stuck in a sending state after a reconnect" (0.23.6), "Recover chat streaming after a stale background-tab WebSocket" (0.23.1) — those cover reconnect paths, not steer-while-subagent-active.

Environment

• kimi-code 0.37.2 (single-binary), macOS arm64
• Web UI in Chrome

Also filed via in-product feedback (id 2467).

Start by reproducing the freeze in the web UI with a running background subagent, then trace the frontend stream subscription or working-state handling when steer and subagent events interleave. Done means the current session continues rendering new events after the steer message, without requiring a session switch.