Pacing §7: avoid both-loops-idle during a handoff (short-poll when blocked on the counterpart)

Root cause of "both waiting": parked-at-gate was lumped into the long idle sleep, so a
pending handoff sat while both loops slept on desynced timers. Fix: three cases — (1) in
flight → ~4m; (2) BLOCKED ON THE OTHER LOOP (Builder at CLAIMED gate / Adversary awaiting a
fix) → ~4m poll for the counterpart, never long-idle; (3) genuinely nothing pending → ~10-15m.
Adversary: a CLAIMED gate is immediate top-priority; otherwise run background probes, rarely
idle while Builder is active. Builder: keep an unblocked item in hand to rarely be fully gated.

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

cc-ci-plan/plan.md

@@ -648,11 +648,21 @@ every wake, `git pull --rebase` first, then:
 
 **Pacing.** Use `/loop` (self-paced) or `ScheduleWakeup`. Most waits here are for things the
 harness can't notify you about — a Drone build, a `nixos-rebuild`, a deploy converging — so poll
-the *specific* thing: while a build/deploy is in flight, re-check on a short cadence (≈4 min) to
-stay cache-warm; when genuinely idle between iterations, sleep ~10–15 min (re-check reasonably
-promptly so the next unit of work is picked up without long gaps — not 20–30 min). But if something
-is clearly still in flight, keep polling *it* rather than treating the iteration as idle; don't burn
-iterations spinning on a build that takes minutes.
+the *specific* thing. Three cases:
+1. **Something in flight** (build/deploy/`nixos-rebuild`) → re-check on a short cadence (≈4 min) to
+   stay cache-warm; keep polling *it*, don't treat it as idle, and don't spin on a minutes-long build.
+2. **Blocked on the *other* loop** — Builder parked at a `CLAIMED` gate awaiting the Adversary, or
+   Adversary waiting for the Builder to fix an `[adversary]` finding → **poll on the short ≈4 min
+   cadence for the counterpart's response; do NOT use the long idle sleep.** A pending handoff is not
+   idleness — the other loop may respond any moment, and if *both* loops long-idle here you get dead
+   wall-clock where neither advances. (This is the common "both waiting" trap — avoid it.)
+3. **Genuinely idle, nothing pending from either loop** → sleep ~10–15 min, then re-orient.
+
+Corollary for the Adversary: a standing `CLAIMED` gate is immediate top-priority work (verify it now,
+don't idle past it); absent a gate, run background break-it probes / re-verify stale D-gates rather
+than sleeping — so the Adversary is rarely idle while the Builder is active. Corollary for the
+Builder: prefer keeping an unblocked backlog item in hand so you're not fully blocked on a gate; only
+hit case 2 when everything is genuinely gated behind the pending verification.
 
 **Anti-drift guards.**
 - Cap retries: if an approach fails 3× the same way, stop, write the dead-end in `DECISIONS.md`,