Review caught that the silent-worker sweep skipped workers with last_frame_ms == 0, so one that wedged before its first handshake was invisible to it. Checking the code, it is worse than invisible: DNS, TLS and the websocket handshake all park on the same read path that lost wakes in the 2026-08-18 incident, and a wedge inside connectAndRead means it never returns -- so run()'s reconnect loop never iterates and there is no backoff to fall back on either. That worker is stuck permanently, and nothing watches it. The signal is now progress, not just delivery: `last_frame_ms` becomes `last_progress_ms`, stamped by addHost at spawn, by run() on every connect attempt, on a completed handshake, and on every frame. So: - wedged pre-handshake -> stops stamping -> swept. - unreachable host looping in backoff -> re-stamps each attempt -> left alone, because it is already reconnecting and does not need help. - connected and delivering -> stamps per frame, as before. Stamping at spawn also removes the window where a worker sat in the map unstamped and would have read as infinitely idle. Unit tests cover both new cases: the pre-handshake wedge ages into candidacy, the backoff loop does not. Verified: zig fmt --check, zig build test, zig build test -Dbackend=zio, and -Dbackend=zio -Dtarget=x86_64-linux-gnu -Doptimize=ReleaseSafe. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>