Follow-ups from #766: an epoll park-retraction arm through a production post-sweep close, and the always-true liveConns guard

[FumingPower3925]

The review of #766 (celeris#711) found no blocking defect. It left two nits. The first needs no change; the second is a test gap.

1. The len(liveConns) == 0 guard before sweepRetract is always true at the park (nit, no action)

Under the park predicate, connCount and liveConns change together at every site, so the guard never skips the retraction. It is harmless and documents the intent, so it stays.

The sites where they change together:

• epoll: adopt.go:199-200, loop.go:995-996, 1742-1748, 2591-2592, 3370-3372, transplant.go:235-239;
• io_uring: worker.go:2051-2052, 2281-2283, 3984-3986, 4104-4106, transplant.go:171-172, transplant_source.go:179-181.

The retraction sits at the only park site in each engine (suspended.Store(true): epoll/loop.go:792, iouring/worker.go:1532 in the merged tree). So it covers every close that follows sweep(), whichever close site a test happens to exercise.

To do: nothing.

2. The epoll post-sweep arm reaches the defect only through a test-disarmed timer (nit)

engine/epoll/park_retracts_residue_test.go:127-131 disarms every loop's timerfd from the test goroutine (unix.TimerfdSettime(l.timerFD, 0, &unix.ItimerSpec{}, nil)) so that the last close lands after sweep() in the parking iteration. The io_uring arm needs no such step.

The PR body says openly that the production paths on epoll that close after sweep() in that iteration are argued, not shown:

• the tick-gate checkTimeouts;
• the detach queue;
• the dirty flush;
• the H2 queue.

To do: add an epoll arm that drives one of those production paths into the parking iteration without touching the timerfd, for example a detached connection closed through the detach queue on a paused loop. It must fail with loop.go's park retraction removed (#766's negative control) and pass on the head.

Refs: #766, celeris#711. Review evidence: evidence/lanes-20260927/EP-2/ (lane) and the reviewer's review-EP-2-evidence/logs/m8/n766.log (negative control: both post-sweep tests FAIL 10/10, busy_parked=1 busy_hold=1).

[FumingPower3925]

3. The epoll pre-sweep control can lose its race with its own header deadline (CodeRabbit, minor)

From CodeRabbit's review of #766 (thread on engine/epoll/park_retracts_residue_test.go:174-179, #766 (comment)).

parkResidue uses one ReadHeaderTimeout (400 ms) for both arms. Before PauseAccept, the fixture waits for the partial request to be read and for TransplantResidualBusy == 1, and each wait may take up to 2 s. PauseAccept does not reset the deadline. The ActiveConnections == 1 check after PauseAccept shows the deadline has not fired yet, but not that time is left. In the pre-sweep arm, the client then sleeps 50 ms before it closes. If the deadline fires first, the close happens at the tick-gate checkTimeouts, after sweep(). The "control" then runs the post-sweep path.

Effect on the head: none. The park retraction clears the gauge on either path, and closes=1 disconnects=1 holds either way. The effect is on the control's power: on a build without the fix, the control could FAIL when it should PASS, so the pair would stop telling the two sides of sweep() apart.

To do: give the pre-sweep arm its own generous ReadHeaderTimeout (for example 10 s) and keep the 400 ms deadline for the post-sweep arm. Close the client as soon as PauseAccept returns, with no 50 ms sleep. Re-run the negative control (loop.go from main): post-sweep FAIL 10/10, pre-sweep PASS 10/10. The io_uring pair should get the same check.

[FumingPower3925]

Consolidated on 2026-10-02 (maintainer decision): polish items -> #885; defects -> none. Nothing was dropped.

Already done or superseded here, per this thread: item(s) 1.