Reconnect dashboard PTY chat after socket drops

[shannonsands]

Summary

• auto-reconnect dashboard PTY chat after abnormal WebSocket closes such as code 1006
• give dashboard-spawned TUIs a per-channel active-session file so reconnects can resume the last live session
• add fresh=1 handling so explicit new-session actions do not resurrect stale sessions
• add focused /api/pty regression coverage for channel resume and fresh starts

Why

The dashboard currently treats unexpected PTY socket drops like terminal session endings. On mobile/background tab interruptions, the browser reports code 1006, the server tears down the PTY child, and the user is left with a dead embedded chat. Remembering the active TUI session per channel lets the reconnect path restore the same conversation instead of starting blank.

Validation

• uv run --extra dev python -m pytest tests/hermes_cli/test_web_server.py::TestPtyWebSocket -q
• npm run typecheck --workspace web

[alt-glitch]

This was generated by AI during triage.

Same goal (survive dashboard PTY socket drops) as the open reconnect cluster #37682 / #47297 / #50084 / #22010 but a distinct per-channel active-session-file mechanism — related, not a duplicate. Maintainers should consolidate the cluster.

[teknium1]

Merged via #52962 — your two commits were cherry-picked onto current main with your authorship preserved in git log (rebase-merge, commit a0dc924). Thanks @shannonsands! The dashboard PTY chat now auto-reconnects on abnormal closes (1006/1001) and resumes the same session via the per-channel breadcrumb file, with fresh=1 for explicit new sessions.