fix(peer): route Tauri events once

[bobleer]

Summary

Fixes the busy-hang where a conversation never settles after a turn completes, so every later message is stuck in the pending queue and only a new conversation recovers.

14c4b5c73 (#2325) moved the stateful runtime-session cursor routing into every logical Tauri listener. SessionStream is a per-(surface, session) ordering gate whose cursor dedup exists to suppress a re-delivered event (snapshot/live overlap), so it must decide about a delivery. With one native listener per logical subscriber, a single delivery was pushed through that gate once per subscriber: the first advanced the applied cursor, and every later subscriber was refused as not-ahead and dropped.

agentic://dialog-turn-completed has several independent subscribers (turn settlement in AgenticEventListener, useAssistantBootstrap, useDialogCompletionNotify, useAcpPlan), so which one received it depended on registration order. Whenever the settlement subscriber was not the winner, the frontend state machine stayed in PROCESSING forever. agentic://dialog-turn-started and agentic://dialog-turn-interrupted have a single subscriber each, which is why only the terminal event was affected.

This cherry-picks the fix from 1.0.0-explore (5bb566c14, authored by @wsp) onto main unchanged, so the two branches do not diverge. Each native Tauri listener is shared across all adapter instances, surface and cursor routing run once per delivery, and logical subscribers are then fanned out. Subscription ownership stays isolated per adapter and held-event delivery semantics are preserved — that also closes the cross-adapter variant that Peer Device Mode can hit while several transport adapters are alive.

Closes #2381

Runtime evidence

Diagnosed on macOS Desktop with instrumentation at the emit site, the host delivery site, the surface gate, the SessionStream admission point and the settlement handler.

Before, for every completed turn: the backend emitted once (emit_lifecycle_events: true, success: true) and the host delivered once, but the webview surface gate saw the event 3 times and SessionStream returned 1 apply + 2 drop. On the reproducing run the settlement subscriber was a drop, so handleDialogTurnComplete never ran and the machine stayed in PROCESSING while the backend was already Idle with the turn persisted.

After, across 13 consecutive turns in 5 sessions: 1 arrival, 1 apply, 0 drop per completed turn, settlement reached finalizeTurnCompletionState 13/13, and 3 messages queued while busy all drained.

Note for the issue reporter: the report attributed the regression to #2372 lock contention. Instrumentation rejected that — the completion path held the mutation lock for ~4 ms, the backend reset to Idle correctly, and the second message was never submitted to the backend at all. The regression source is #2325.

Test plan

• pnpm --dir src/web-ui run test:run src/infrastructure/api/adapters src/infrastructure/peer-device src/flow_chat/session-stream — 14 files, 137 tests pass
• pnpm run type-check:web — no errors in changed files (3 pre-existing @/generated/api errors come from the gitignored codegen artifact, .gitignore:51)
• Desktop, local workspace: 13 turns across 5 sessions settle, including turns with 13/20/28/31/40 tool rounds, session switches mid-turn, and messages queued while busy
• Peer Device Mode cross-adapter fan-out — covered by the added regression tests, not exercised on hardware