nx_tls13_frag_gate.nx

nx_tls13_frag_gate.nx -- THE GATE FOR TLS REQUEST FRAGMENTATION ARITHMETIC, 2026-09-04. SUBJECT: nx_tls13_frag_max / nx_tls13_frag_len / nx_tls13_frag_count, in-process. WHY THIS GATE EXISTS AT ALL. Until today nx_https_req_complete wrote every request as ONE TLS record, so the transport had a hard ~16 KB ceiling that callers wore as hand-picked body constants. MEASURED: a 6,100-byte payload produced an 8,369-byte body and was refused while 5,900 passed, and the sovereign content shipper could not send the 48,402-byte chunks its own server offered -- around forty abandoned transfers had piled up over eleven days while each failure reported only "post failed". Fragmenting fixed it. But that change is in a shared transport every HTTPS client in this estate imports, and it goes live for each of them silently, on their NEXT REBUILD. A change with that blast radius must be testable without a socket. WHY IT GATES PURE ARITHMETIC AND NOT A LIVE SEND, on its sibling nx_https_post_lib_gate precedent: a gate that opens a socket goes RED when someone else network fails, and its RED then indicts this code for another outage. The split was extracted out of the loop precisely so it could be walked exhaustively here as integer arithmetic over one argument. THE LOAD-BEARING TOOTH IS THE PARTITION. Every off-by-one in a chunking loop either DROPS bytes or DUPLICATES them, and both survive a boundary test that only checks counts. Asserting that the fragment lengths SUM BACK TO the request length is the check that cannot be passed by a wrong split. license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0