nx_poolwidth_lib.nx

nx_poolwidth_lib.nx -- ONE headroom-derived width governor for every pool in the ecosystem (seq1402). THE DEFECT, MEASURED 2026-07-30: nx_torrent_get.nx:717 carries `let MAXP: i64 = 32` -- a hardcoded literal (rule-11) -- and refills every free slot every 2s. That is 16 forks/sec PER INSTANCE. The box measured **143 forks/sec at load 11.72 on 8 threads**, which is ~9 concurrent instances. NOBODY CHOSE 143. It is 32 x N, and N is whatever the operator queued. ★★LAW: A PER-INSTANCE LIMIT IS NOT A LIMIT. N instances multiply it and nobody ever picks N. ★WHAT THIS IS *NOT*: a backoff. nx_torrent_get.nx:711-716 documents constant connection cycling as the BitTorrent throughput strategy (continuous optimistic-unchokes vs fast-burst-then-freeze). Throttling the CYCLING would attack the feature to flatten a graph -- operator rule 25, build intelligence, never strip it. This governs only the WIDTH; inside its budget the pool stays as aggressive as it ever was. The same law already bit the crawl pool (seq1288 saturation-wedge: "pool width must be HEADROOM-DERIVED"). Two lanes, one defect => ONE primitive, not two fixes (rule 15). license_tier: ORIGINAL Pure. No hw writes (Rule 26).