Broadcast user messages to parallel clients

[GrigoryPervakov]

Summary

• A chat message sent from one web client was only rendered optimistically on the sender. Other connected clients — and the same user in a second tab — saw the assistant reply appear with no preceding user bubble until they reloaded the session.
• The inbound WS message handler now echoes the user's text over the session channel via a new user_message event, excluding the sender (which already showed it optimistically). Parallel clients append the bubble live; engine.run still persists the message, so reloads continue to source it from history.
• Adds an exclude argument to StreamBroadcaster.broadcast (skip one listener by callback id) and a unit test.

Why

Streaming events (token/tool_*/done) and session_running already reach every client, but the user's own message text was never broadcast — only the sender optimistically rendered it. So a parallel viewer got a reply with no question.

Dedup / correctness

• The sender is excluded by client_id, so it never double-renders its own optimistic bubble.
• The buffered user_message is ignored by applyStreamEvent on reconnect replay, and persisted history is the source of truth on full reload — no duplicate bubble in either path.
• Image/file messages re-render via hydrateMessage from the broadcast blocks (the persisted image refs).

Test plan

• Open the same session in two tabs → send from tab A → tab B shows the user bubble immediately, followed by the streamed reply
• Sender tab shows exactly one bubble (no duplicate)
• Reload either tab → message present once (from history)
• Image/file message appears with attachments on the parallel client
• pytest tests/test_streaming.py green; npm run build clean

Out of scope (audit — other parallel-client gaps found)

Not addressed here; flagging for triage. These are sidebar/REST-level and warrant their own change (some need new events):

• Manual title rename and star toggle (PATCH /api/sessions → update_session) don't broadcast — other clients' sidebars update only on reload.
• fork / resume reply to the originating client only (websocket.send_json), so other clients don't learn of the new/resumed session live.

🤖 Generated with Claude Code