Watchdog handoff signalling: ping the waiting loop on gate-claim / verdict (kill double-idle)

launch.sh watchdog now runs a fast (~30s) handoff_check alongside the heavy (300s) restart/DONE
check: when the Builder writes a CLAIMED gate it pings the Adversary to verify now; when the
Adversary updates REVIEW.md it pings the Builder to proceed (edge-triggered, reads local clones).
So a pending handoff resolves in <~30s instead of a whole idle interval. Pacing revised: the
Adversary may idle freely when nothing's pending (no pointless re-verify/busy-poll) and is woken
by the watchdog; Builder waits on the ping + a fallback ~2-4m self-poll. kickoff documents the
new "handoff signalling" role.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

cc-ci-plan/kickoff.md

@@ -37,9 +37,13 @@ ownership keeps concurrent pushes merge-clean.
 |---|---|---|
 | **Iteration** — keep doing one unit of work, then wake again | `/loop` self-paced (ScheduleWakeup), per plan §7 pacing | each agent, in-session |
 | **Resilience** — restart a loop whose process/sandbox died; stop all on `## DONE` | `launch.sh` watchdog (tmux + git poll) | this script |
+| **Handoff signalling** — wake the *waiting* loop the moment its counterpart hands off | watchdog `handoff_check` (~30 s): Builder writes a `CLAIMED` gate → ping Adversary to verify; Adversary updates `REVIEW.md` → ping Builder to proceed | this script |
 
 `/loop` alone is bound to its process: if the sandbox restarts, that loop is gone until something
-relaunches it. The watchdog is that something. Use both.
+relaunches it. The watchdog is that something. It also closes the **double-idle gap**: instead of a
+pending gate/verdict sitting until the other loop's next scheduled wake, the watchdog pings the
+waiting loop within ~30 s — so the Adversary can idle freely when nothing's pending (no busy-polling
+or pointless re-verifying) yet still start verifying right after the Builder parks at a gate. Use all three.
 
 ## Launch