docs(handoff): two tmux crashes in 24h, both recovered by hand — and autorecovery did nothing for 8.5 hours

[ZacxDev]

Records the 2026-09-11 crashes and the operator's 7-day retention ask.

Two crashes, 00:08 and 02:23. Both recovered by hand, neither attributed: no OOM (0 matches against a positive control of 54), no coredump, nothing logged at teardown. My own audit subagents are ruled out — the last finished 50 minutes before crash 2 (on 2026-09-07 the agent's kill was 72 seconds before).

The second went undetected for 8.5 hours, and that is a design flaw, not a malfunction. Two individually-correct refusals compounded:

1. 02:37:14 no tmux server is running — REFUSING to restore. — fix(tmux-restore): REFUSE when there is no tmux server, instead of manufacturing one systemd then kills #1351's guard, correct (starting one in the unit's cgroup lost 43 conversations on 2026-09-06). But it exits 0 by design, nothing retries, and nothing else on this host starts tmux.
2. 11:00:02 restore plan is out of step with the saved layout by 8.6h — the crash spawned a new server, resurrect saved the degraded layout, and that made the good 53-conversation plan look stale. The guard against restoring a stale plan blocked recovery at exactly the moment it was needed — the same inverted-basis shape fix(tmux-restore): the staleness gate counted POWERED-OFF time against the plan #1317 fixed for powered-off time.

🔴 #1494 performed both recoveries and is still unmerged, so main carries the window_state false positive and the bare-claude send. That is rank 1.

On the 7-day ask: "store all saves instead of just the most recent" is already shipped (#1383) — generations are live on both hosts. The real delta is 48h → 7d: KEEP_GENERATIONS 192 → 672, measured at ~34 KiB per generation, so ≈22 MiB (4 MiB today).

Also records the reusable recovery procedure that worked twice, and that the save side protected the plan both times (no live claude panes found — nothing to snapshot).