[BUG] Remote Control: ended sessions stay "Connected" — stale entries accumulate, never reaped

Summary

Remote Control sessions that have ended (their local claude process exited) continue to show a green "Connected" badge in the mobile app's Code list and never get reaped. Over time this accumulates to dozens/hundreds of stale "Connected" entries.

Environment

• Claude Code 2.1.170 (well past the v2.1.113 archival fix)
• macOS 15 (Apple Silicon)
• Sessions launched via the cmux terminal, many with --remote-control

Symptom

The mobile Code list shows dozens–hundreds of sessions with the green "Connected" dot. Verified on the host machine that only ~8 claude processes are actually alive, while ~132 top-level sessions exist locally — so the overwhelming majority of "Connected" badges are stale. The status is never cleared after the host process exits.

Steps to reproduce

1. Start several claude --remote-control sessions.
2. End them uncleanly — close the terminal/pane, kill the process, or let the laptop sleep — rather than /exit.
3. Observe the mobile Code list: the sessions keep the "Connected" badge indefinitely instead of flipping to Disconnected/archived.

Expected

Per the Remote Control docs and #50147 / the v2.1.113 archival fix, a session whose host process has exited should be reaped — flipped to Disconnected and/or archived out of the active list — not left showing "Connected".

Actual

Ended sessions remain "Connected" forever. There appears to be no reliable server-side reaping/heartbeat-timeout when a process dies without a clean teardown (force-close, kill, sleep, reboot, crash). Clean /exit does deregister; unclean exits strand the entry.

Impact

Cosmetic/UX — no live process or compute is attached to the stale entries — but the list becomes unusable for finding genuinely-live sessions, and the "Connected" badge is misleading.

Questions this also surfaced (please clarify in docs)

• What happens when a user taps an archived session to resume it when the original working directory/repo no longer exists on disk? Is it a graceful failure, a fresh claude --resume <id> spawn on the host, and is it ever destructive?