fix(router): re-time settled adaptive routes so a store that turns slow no longer pins the worker forever

[FumingPower3925]

Fixes #592 (measured under #589). The rig that found the defect judges the fix, the negative control was run, and an adversarial reviewer re-read the pushed diff rather than the report.

Reviewer verdict

Finding closed: True. Mergeable: True.

All three binding findings are closed in the pushed tree, verified by reading the diff and re-running tests myself, not from the report. (1) START ORDER: server.go:675 calls startSettleReopener after createEngine's error return and after engineRef.Store(&eng); Shutdown (server.go:370) stops it before the loadEngine()==nil early return. TestRouteAdaptive_NoReopenerWhenEngineCreationFails gates it with a genuine discriminator (a Std server that starts must show reopenStop != nil and a live "created by ...startSettleReopener" frame, and zero after cancel), so a tree that simply never starts the ticker cannot pass; PASS under -race -count=2 locally. (2) CLAMP: router.go:400-403 is if c := fv.(*atomic.Int32); c.Add(1) >= adaptiveSettleStreak { c.Store(adaptiveSettleStreak); r.settled.Store(...) }; the wrap argument is correct (unclamped, the re-opener adds >=1 per tick forever and a negative int32 makes Add(1) >= streak unsatisfiable, permanently re-introducing per-request timing). TestRouteAdaptive_FastStreakClampedAcrossReopens asserts 0 <= streak <= 256 over 10,000 cycles and 1,000 in-window runs plus the slow-run zeroing; PASS under -race. (3) DOC: the corrected cost model appears in all three sites (handler.go adaptiveSettleTTL, router.go reopenSettled, config.go Config.AsyncHandlers) and I independently reproduced its shape: GOMAXPROCS=2 -race gave timed_per_reopen 1.00/1.07/1.28/1.24 and max_timed_in_one_reopen 1/2/4/4 at K=1/2/4/8, i.e. max <= K, matching the claim of one timed run per concurrently-executing inline handler per tick. git diff 385700d..HEAD on non-test files is EXACTLY these three changes and nothing else (two code lines + doc text), so no scope creep. Hot path is untouched: handler.go:141-155 byte-for-byte identical, adaptiveLearning unchanged, the added Store is on the learning branch only. settled.Clear() requires Go>=1.23 and the module is go 1.27.0. gofmt clean on all six files; go vet clean for darwin and GOOS=linux. Only 6 files in the diff, no scratch files, no debug prints (RESULT592/MEASURE592 are t.Logf, matching house rig style); scratch worktrees are outside the repo and the main worktree is clean. The rig's only change versus the reviewed commit is the SO_REUSEPORT worker-count readiness wait plus a richer fatal message, a real apparatus fix that still fails on a genuine memlock cap.

Residuals the reviewer recorded

1. CI COST / TIMING RISK, the one thing I would fix before merge. TestRouteAdaptive_SettleReopenCost lands in the DEFAULT race job: .github/workflows/ci.yml:120-123 runs go test -race -count=1 -timeout=300s over the root package and never passes -short, so its testing.Short() skip does nothing in CI. I measured 35.4 s at GOMAXPROCS=2 under -race, saturating every core; that step takes 154 s today (run 34790598323). It is exactly the class of test whose exclusions that job's own comments enumerate (./adaptive/..., ./middleware/websocket). It also self-disables its load-bearing concurrency bound whenever a jitter run fires (~40% of -race runs at K=8 by the agent's own data), and a >2 ms jitter run calls promoteRouteImmediate, closing the gate for adaptivePromoteTTL = 5 s while waitSettled can only spin against its 30 s fatal deadline. Suggest an opt-in env gate like the other rigs, or capping runners at 4.
2. CONFIRMED, agent's own still_open Engine interface and core types #2: Start (server.go:354-360) returns eng.Listen()'s error, the caller typically never calls Shutdown, and the ticker runs to process exit. Same shape as closeCPUMonitor, which is also Shutdown-only, so it is consistent with the existing lifecycle and correctly left out of the three findings' scope.
3. MINOR, new: promoteRouteImmediate's comment says "the fast streak is cleared so a burst of prior fast runs cannot settle the route once the promotion TTL expires". A concurrent fast run whose Add reads the pre-reset value now also writes Store(256) after the Store(0), restoring "one fast run from settling". The analogous settled.Store-after-reset window pre-existed, and adaptiveLearning is false while promoted so no further timed runs happen, but the nearby comment is now marginally stronger than the code.
4. SCOPE NOTE for adaptive dispatch never re-times a settled route: a store-backed handler that turns slow runs inline on the engine worker forever (#493 item 4, measured) #592 reviewers: the fix bounds inline pinning at adaptiveSettleTTL + one request (measured promote latency p50 5.42 s against the rig's 8 s bound); it does not eliminate the stall window. That is the documented design.
5. Unchanged and correctly scoped out: celeris#593 keeps io_uring stalled_frac ~0.31 in all three modes; the rig asserts the stall bar on epoll only and prints io_uring.
6. No PR exists yet for fix/592-settled-route-retime, and the branch is one commit behind origin/main (42d1643, an unrelated test file).