Session crash: OOM from zombie Claude processes + missing crash telemetry

What happened

Session died and restarted mid-conversation (observed twice today, Mar 17). User clicked a share link right before the second crash, but the root cause is memory pressure, not the share link itself.

Root cause

8 concurrent Claude processes running, consuming ~3.2GB RSS. Swap is 99% full (1.0Gi used, only 10Mi free).

claude  6.2%
claude  5.7%
claude  5.4%
claude  5.0%
claude  4.9%
claude  4.6%
claude  3.9%
claude  3.1%
Total claude RSS: ~3.2 GB
Swap: 1.0Gi / 1.0Gi (10Mi free)

Zombie/orphaned sessions from previous conversations accumulate and are never cleaned up. Eventually the OOM killer terminates one — whichever process it targets, which may be the active session.

This extends #67 (OOM from zombie accumulation) with a concrete reproduction.

Secondary problem: no telemetry

When the session dies, there is no:

• Notification to the user that a session was killed (vs. completed normally)
• Log of which session died, when, what killed it, or what it was doing
• Memory pressure warnings before the kill happens
• Distinguishable exit code between OOM kill (SIGKILL, exit 137) and normal completion

The user found out by noticing the session had restarted — not from any system alert.

What's needed

1. Fix zombie accumulation — sessions that have exited (check via tmux + exit code) should be reaped: Claude process killed, tmux session closed, registry marked dead
2. Memory pressure warnings — alert user when available memory drops below threshold (e.g. <20% or swap >80%)
3. Crash telemetry — distinguish OOM kill (exit 137) from normal exit, send Telegram notification when a session is unexpectedly killed
4. Session health dashboard — show running sessions + their memory usage so user can see what's alive

Related

• #67 OOM kills from zombie accumulation
• #125 Dog needs indexed context (dog should know which sessions are alive)
• #122 spawn proxy drops registration on child exit

No files, tests, or entry points are named. Start by tracing the session registry, tmux lifecycle, and child-exit handling described in the issue, then review the related issues #67, #125, and #122. Done means zombie sessions are reaped, memory pressure and unexpected exits are reported, and running-session health is visible.