Session status stays "Connected" indefinitely after the CLI process dies ungracefully — no heartbeat timeout

Summary

When the CLI process behind a Remote Control session dies without a graceful shutdown (killed, crashed, power loss), claude.ai and the mobile app keep showing the session as "Connected" indefinitely. There appears to be no heartbeat/liveness check on the backend — the status only changes on an explicit disconnect event, which a dead process can never send.

Environment

• Claude Code 2.1.217, Windows 11, Max plan
• Server: claude remote-control (spawn=same-dir), session started from the Claude mobile app
• Observed on both the mobile app and claude.ai/code session list

Repro

1. Run claude remote-control (server mode) on the host. From the mobile app, start an on-demand session.
2. On the host, kill the session's CLI process (e.g. Stop-Process -Id <pid> on Windows). The process disappears from claude agents --json immediately.
3. Watch the session in the mobile app / claude.ai session list.

Observed: the session still shows "Connected" (green) 15+ minutes after the process died, and stays that way indefinitely. The only cleanup is manually archiving it.

Expected: after some heartbeat timeout (say 1–2 minutes without liveness from the CLI), the session should flip to "Disconnected", like sessions whose server process ended gracefully do.

Notes

• Killing the process is not an exotic path: for server-spawned sessions it is currently the only way to end one, because /exit from the client is denied and claude stop doesn't apply — see #80095. But even with that fixed, crashes and power loss would still leave permanent "Connected" ghosts.
• Opening the ghost session from a client behaves like #60790 (CLI owner is gone).
• Same family of stale-state-over-Remote-Control as #67404 (activity badge showing tasks that no longer exist).

Related: #80095, #60790, #67404