test(engine): wait for every client before counting accepts in the #662 queued-accept rig

[FumingPower3925]

Summary

Test-only fix. Main's Unit job went red on c4d1cb5 (run 35428669128) in engine/epoll:

--- FAIL: TestPauseAcceptQueuedControl (0.42s)
    pause_accept_queued_linux_test.go:199: pause=false workers=2 blockers=3 queued=8 outcomes=map[200:8] accepts=10 (before release 2) closes=0 errors=0 onConnect=10
    pause_accept_queued_linux_test.go:214: AcceptCount = 10, want 11 (3 blockers + 8 queued): every connection the engine takes off an accept queue must be counted
    pause_accept_queued_linux_test.go:262: after client close: active=0 accepts=11 closes=11 onDisconnect=11 errors=0

Cause. The rig holds every loop inside a blocking handler.

• With 2 loops, it took 3 dials to get both loops into the handler. The second dial landed on a loop that was already held, so it waited in that loop's accept queue. That is why accepts before the release = 2.
• After the release, the test waited only for the 8 queued connections' responses, then read AcceptCount.
• Nothing orders the extra blocker's accept before those 8 responses. If every queued connection hashes to the other loop, all 8 can answer while the held loop has not yet come back to its queue. The count then reads 2 + 8 = 10.
• The log's own last line shows the connection was accepted and counted right after: 11 accepts, 11 closes.

The engine is fine; the test raced its own measurement. The io_uring copy of the rig (engine/iouring/pause_accept_queued_linux_test.go) has the same gap. It cannot trip in CI's one-worker Unit shape, but it can at two workers.

Fix. Both copies now also wait for every blocker's response before reading the metrics. The blockers' responses are still unscored. A response exists only after its connection was accepted and counted: AcceptCount is an atomic add at accept time, at engine/epoll/loop.go:939 and engine/iouring/worker.go:1913. So once every client has a response, the check is exact, with no polling and no new timing.

Proof, on the runner

The commits go up in order:

1. The fix plus a throwaway mutant in engine/epoll/loop.go that makes each loop skip counting its first accept, the smallest real miscount. CI on this head must fail the two queued-accept tests on the count checks. This shows the fixed test still catches a lost accept.
2. The mutant removed. CI must pass.

The run links will be added below. The squash merge carries no mutant.

This waits to merge until the #657 PR-2 branch has opened its PR, because both touch engine/.

[FumingPower3925]

Proof on the runner, as described above:

• Mutant head 1323f28 (each epoll loop skips counting its first accept), CI run 35428984685. The Unit job failed exactly the two queued-accept tests on the count checks:
  • TestPauseAcceptServesQueuedConnections: AcceptCount = 9, want 11, OnConnect fired 11 times for 9 accepts, CloseCount = 11, AcceptCount = 9.
  • TestPauseAcceptQueuedControl: AcceptCount = 12, want 14, again with the matching OnConnect and CloseCount mismatches. This run had 6 blockers, 4 of them extra connections waiting in a held loop's queue, the case that raced before. The fixed rig still counted every one of them except the 2 the mutant dropped.
  • The same run's Adaptive failure is not the mutant. It is TestReverseTransplant "did not converge: epoll=59, err=5", the known adaptive: forced switches leave keep-alive connections behind — async conns miss the 1.2 s flap window in every run, and a one-worker io_uring strands sync conns until their requests fail #657 revert loss that the adaptive: forced switches leave keep-alive connections behind — async conns miss the 1.2 s flap window in every run, and a one-worker io_uring strands sync conns until their requests fail #657 PR-2 fix addresses.
• Mutant removed, 4d534d0, CI run 35429160974: every job passes, including Unit and Adaptive. engine/epoll/loop.go is byte-identical to main, and the branch differs from main only in the two test files.

This merges once the #657 PR-2 branch has opened its PR.