fix(ws): surface offline-session sends instead of silently dropping

[finedesignz]

Summary

The hub forwarded user_message to channel.ws.send() whenever an entry existed in the channel registry — with no liveness check on the underlying socket. A half-open WS (TCP dead, close not yet observed) returns a positive byte count from send(), the hub logs forwarding to channel, and the message vanishes. No agent processes it, the UI shows nothing, and the user assumes their send went through.

Symptom seen in prod logs:

[agent] authenticated session=41d0cb2c... reused=true
[client] send_message session=41d0cb2c...
[client] forwarding to channel session=41d0cb2c...

…repeated forever with no text_delta/thinking/tool_use/assistant_message ever following.

Fix

• Hub (hub/src/ws/client.ts): before forwarding, check channel.ws.readyState === 1 (OPEN). If not — or if send() returns -1 — unregister the stale entry, broadcast session_status: offline, and emit a structured send_refused { error: 'session_offline', reason } back to the SENDER.
• Web (useWebSocket.ts): clear the in-flight queue entry on send_refused so the reconnect replay doesn't resurrect a message we already told the user failed.
• Web (useChat.ts, useChatSurface.ts): render the refusal inline as a transient assistant bubble (status: 'interrupted') so the user sees WHY there's no response and can reconnect their agent.

Test plan

• bun run build:web clean
• Existing hub unit tests still pass (bun test hub/test/ — same baseline failures unrelated to ws/client.ts)
• Manual prod verification: with no claude-remote running, send a message → expect inline "⚠ No live runner is attached…" bubble + session badge flips to offline
• With claude-remote running, normal chat flow unaffected

🤖 Generated with Claude Code