fix(rtmg): reap dead-client sessions so a half-open WS can't wedge a pod

[leszko]

Problem (observed in prod)

Two fleet pods became unconnectable while still heartbeating "healthy" — the only recovery was destroying them. SSH diagnosis:

Pod	GPU	Connected WS sockets	conn_handler threads
A	74–95%	0	236
B	0%	0	242

Pod A was a zombie: the runner kept generating audio at full GPU with zero connected clients, still holding the one-session-per-pod seat. Its session log showed a session that took the seat hours earlier and never tore down.

Root cause

When a client's transport half-opens — tab closed without a close frame, a network drop, or (common with our Cloudflare named tunnels) a half-open TCP — ws.send buffers into the dead socket instead of raising ConnectionClosed. Every teardown path keys off state.running, which is only flipped on ConnectionClosed, so the session runs forever.

The WS keepalive can't be the sole backstop: server.py deliberately widened ping_timeout to 90s to avoid GIL-starvation false-disconnects, and its own comment says to "pair with an app-level idle-session reaper." That reaper didn't exist — this adds it.

Fix

A per-session daemon reaper (_dead_client_reaper) in _handle_client_body:

• Signal: the client acks every received slice (monotonic byte count, already tracked in _slice_flow). The reaper acts only while we're actively sending slices (sent advancing) and the ack count has stalled for _DEAD_CLIENT_ACK_TIMEOUT_S (default 30s, env DEMON_DEAD_CLIENT_ACK_TIMEOUT_S). That's the exact zombie fingerprint: generating hard, acks frozen.
• Action: flip state.running (runner tears down on its next iteration) and ws.close() to unblock the hung send/recv. Closes without send_lock on purpose — closing is what unblocks a send hung inside that lock.

Why it won't false-reap

• An idle-paused session sends no slices, so sent doesn't advance and the reaper never fires. Idle+dead is left to the WS keepalive (the GPU is free while idle, so the keepalive thread isn't GIL-starved).
• acked_ts seeds at session start, so a client that never acks at all is also caught after the timeout.
• The reaper is a daemon thread that self-exits when state.running flips, so it adds no teardown coupling and can't itself leak.

Test notes

• py_compile clean. The change is additive (one new daemon thread + one timestamp field); the existing flow-control/drop path is untouched.
• Recommend validating on a :dev pod: start a session, kill the client's network (or close the tab uncleanly), confirm GPU returns to idle within ~30–35s and dead_client_reap is logged, and that a fresh connection then succeeds.

Follow-ups (not in this PR)

• The ~240 leaked conn_handler threads look like a second issue (handshake/HTTP-probe connections not being reaped); worth a separate look.
• Fleet-side safety net (in demon-public-demo): have the orchestrator/pool detect a wedged-but-heartbeating pod and bounce its session process instead of relying on manual destroy.