feat(tui-gateway): add websocket transport foundation for dashboard chat

[DChells]

Summary

Ports the transport layer from #12710 onto current main so tui_gateway can speak the existing JSON-RPC protocol over either stdio or WebSocket.

This PR intentionally stops at the transport boundary. It does not include the /chat dashboard UI.

Why

#12710 showed the right overall architecture, but it bundled two separate review surfaces into one PR:

• transport / protocol plumbing
• dashboard chat UI

Per the contribution guidance to keep PRs focused to one logical change, this PR isolates the backend foundation first.

That keeps the review question narrow:

Is a transport-aware tui_gateway plus authenticated /api/ws the right foundation for native dashboard chat?

It also preserves current main behavior around runtime provider resolution and graceful state.db failure handling instead of trying to merge an older branch wholesale.

What changed

• added tui_gateway/transport.py
  • minimal Transport protocol
  • contextvar-based request transport binding
  • StdioTransport wrapper for current stdio behavior
• added tui_gateway/ws.py
  • WSTransport implementation
  • WebSocket JSON-RPC receive/send loop
  • gateway.ready emit on connect
  • parse-error handling and disconnect cleanup
• updated tui_gateway/server.py
  • transport-aware dispatch() / write_json()
  • request transport propagation into pooled handlers
  • session-bound event routing to the owning transport
• updated hermes_cli/web_server.py
  • authenticated /api/ws endpoint using the existing dashboard token
• added focused tests in tests/hermes_cli/test_web_server.py
  • auth rejection
  • parse error / unknown method
  • inline vs pooled handler round-trip
  • session event routing
  • disconnect cleanup
  • stdio / WebSocket parity

How to test

python -m pytest tests/hermes_cli/test_web_server.py -k 'TuiGatewayWebSocket or TuiGatewayTransportParity' -q
python -m pytest tests/test_tui_gateway_server.py -q
python -m pytest tests/hermes_cli/test_web_server.py -q

Tested on

• Ubuntu Linux

Observed locally after rebasing onto current main:

• 13 passed — focused WebSocket/parity slice
• 52 passed — tests/test_tui_gateway_server.py
• 123 passed — full tests/hermes_cli/test_web_server.py

Cross-platform impact

This change touches transport/session routing inside the Python gateway and the FastAPI WebSocket endpoint. It does not add shell-specific behavior or platform-specific path logic.

I only tested on Linux, so Windows/macOS verification would still be useful from maintainers or CI.

Related issues / PRs

• Fixes Split from #501: define Phase 1 Web UI gateway MVP contract #8183
• Refs Feature: Web UI Gateway — Local Browser-Based Interface with Streaming, Artifacts & Rich Rendering #501
• Refs feat(tui-gateway): WebSocket transport + /chat web UI, wire-compatible with Ink #12710
• Refs Feat/dashboard chat #13379
• Refs fix(dashboard): persist and scope profile switching #13823

Notes for reviewers

• This is intentionally one logical change: transport foundation only.
• The follow-up dashboard UI work is split into feat(dashboard): add native /chat page on top of tui_gateway websocket transport #14815.
• The main architectural goal is one dispatcher with two transports, without duplicating handler logic.

[teknium1]

Thanks for the thoughtful PR and for splitting the transport foundation from the dashboard UI (@DChells)! This is an automated hermes-sweeper review.

The transport layer this PR proposes is already present on main — it landed two days before this PR was filed:

• tui_gateway/transport.py — Transport protocol, StdioTransport, TeeTransport, bind_transport/current_transport/reset_transport — all present (commit f49afd312)
• tui_gateway/ws.py — WSTransport + handle_ws with gateway.ready emit, parse-error handling, disconnect cleanup — all present (commit f49afd312)
• hermes_cli/web_server.py line 2489 — @app.websocket('/api/ws') with token-gated auth calling handle_ws — already live
• tui_gateway/server.py lines 286–407 — transport-aware write_json() and dispatch(req, transport) — already present

The follow-up dashboard UI PR #14815 is the right place to continue — the foundation it depends on is already in place.