nx_torrent_backoff_gate.nx

nx_torrent_backoff_gate.nx -- does the seeder stop burning a core when nothing it accepts can be served? ★THE DEFECT THIS PROVES (measured live 2026-07-30). `nx_torrent_seed` held ~71.6% of a core with the signature of a hot accept loop. Two independent faults, one symptom: (1) BOTH accept loops read `if afd >= 0 { ... }` with NO else branch. A persistently failing sys_accept (EMFILE / ENFILE / ECONNABORTED) therefore re-looped with ZERO delay -- an unconditional spin at whatever rate the CPU allows. (2) The forked child called `sys_exit(0)` UNCONDITIONALLY, so the parent could not observe that `ts_serve_peer_registry` was returning -2 every single time. /tmp/seed.log showed `served blocks=-2` repeating without end while the parent forked again immediately, forever. ★A LOOP THAT CANNOT SEE ITS OWN FAILURES CANNOT BACK OFF FROM THEM. The exit code was the missing wire. ★WHY A PURE FUNCTION IS THE UNIT UNDER TEST. "every peer handshake fails" is not a host state you can summon on a shared box, so a policy welded into an accept loop beside its own syscalls is untestable in practice -- which is exactly how it survived. Same discipline as `hc_keep_delay` and `ba_verdict`. ★THE TOOTH THAT MATTERS IS T6, the NEG-CONTROL: the pre-fix policy is kept alive as `ts_backoff_ms_old` and asserted to return 0 on the very inputs where the fix backs off. If someone reverts the fix, T2/T3/T4 go green against a spinning loop unless a tooth pins the OLD behaviour to the OLD answer. A gate that cannot fail on the unfixed code proves nothing about the fixed code. usage: nx_torrent_backoff_gate (CWD = the store root) exit 0 = GREEN · 1 = RED license_tier: ORIGINAL expect_exit: 0