[Param-Harrison]

Problem

pollOnce kept every issue of a batch in inFlight until the whole batch finished. An issue that parked mid-batch (plan awaiting approval, open question) stayed invisible to later polls, so a human's /factory approve sat unread until the batch's slowest issue finished its build and verify.

Seen on kaas-suite: cards 34 and 36 were approved at 07:47 and 07:48 and did not start building until card 35, from the same batch, parked at needs-human about twenty minutes later.

Fix

• Each issue leaves inFlight when its own dispatch ends (src/watch.ts).
• That widens a race that already existed at batch end: a poll that listed issues before an issue's release holds a stale copy (still ready, say) and would dispatch it a second time. Each release now records a sequence number, and a poll skips any issue released after it started listing. A background security review of the first commit flagged this; the second test reproduces it.

Evidence

• tests/continuous-dispatch.test.ts: two new tests. Both fail without their half of the fix (an issue still in inFlight after it parked; starts of [1, 1] from a stale poll).
• tests/mutations.json: one entry per half; both bites in make check-mutations.
• make check: 1726 pass, 0 fail.
• make check-mutations: 332 of 334 bite, including both new ones. The other two failed before mutation on guard-hook.test.ts timeouts while three other gates were loading the machine. That file passes 3/3 run alone, and this change does not touch it.

Not in this PR

• No version bump. The release (v4.0.2) can go with the next tag.
• The verify stage's mutation copy failing its baseline in target repos (kaas-suite: 5 tests that need git history or a sibling checkout) is a separate issue.

🤖 Generated with Claude Code