nx_https_truncation_gate.nx

nx_https_truncation_gate.nx -- teeth for the TLS-1.3 short-body check in nx_https_get_complete.nx. THE DEFECT IT GUARDS: nx_https_req_complete computed body_target from the peer's Content-Length and then IGNORED IT at three of its four termination exits (record EOF, payload EOF, close_notify alert), so a body the peer cut short returned as a POSITIVE byte count and every caller read positive + 200 as success. The TLS-1.2 sibling leg has checked the same number since 2026-08-18; this gate exists so the 1.3 leg cannot silently lose it again. IN-PROCESS BY CONSTRUCTION: it imports nx_https_get_complete.nx and calls nx_https_body_state, nx_https_body_shortfall and _gc_body_seal DIRECTLY, so it exercises the same code the transport runs rather than parsing a fetcher stdout. That also means it has no NOT-DEPLOYED failure mode -- a gate that forks a deployed elf reports INCONCLUSIVE when the subject is merely un-promoted, which reads as the gate own fault. FIXTURES ARE BYTE BUFFERS ASSEMBLED IN THIS PROCESS, AND THAT IS THE STRONGER FORM OF THE /tmp/<gate>/ LAW, NOT AN EXEMPTION FROM IT. The rule exists because a gate must not share its fixture with a production beat; a buffer that lives and dies inside one process shares nothing with anything, and there is no /tmp file here because there is no FILE anywhere in the code path under test. A gate that wrote a file purely so it could read it back would be testing the filesystem, not the predicate. Every buffer is rebuilt from scratch per tooth, so the gate is idempotent by construction. THE FIRST TOOTH IS THE ANTI-VACUITY ONE. The trivial wrong implementation is "call everything truncated", and it would pass every detection tooth below. Only the positive controls -- complete bodies that must NOT be flagged -- can refute it. A GUARD THAT REFUSES EVERYTHING PASSES EVERY NEGATIVE TEST. license_tier: ORIGINAL expect_exit: 0