nx_fetchwall_lib.nx

nx_fetchwall_lib.nx -- IS THIS FETCHED BODY CONTENT, OR A WALL WEARING A 200? (2026-09-03) WHY THIS EXISTS, MEASURED THE DAY IT WAS BUILT. A Google AI Mode share link was fetched by the sovereign client, which reported status=200 body_bytes=92982 SAVED ... grep it to cite. Every one of those words was true and the artifact was a JavaScript gate: title Google Search, a noscript meta-refresh to /httpservice/retry/enablejs, and not one character of the answer. A WALL THAT RETURNS 200 AND 93 KB IS INDISTINGUISHABLE FROM A MIRROR UNTIL SOMEONE READS THE HEAD, and the refs lane cites mirrors by path, so a wall silently becomes a fabricated citation carrying a real provenance row and a real sha256. WHAT IT IS NOT. It is not nx_mirrorintegrity, which measures TRUNCATION -- a different axis that reads this very file as intact, because it IS intact; it is a complete wall. It is not nx_clean_serve, which is a policy transform. The question here is prior to both: does this body carry readable content at all. THE ORDERING IS THE WHOLE DESIGN: STRUCTURE DECIDES WHETHER, MARKERS DECIDE WHICH. The structural axis is bd_fit_text from nx_block_density (Kohlschuetter shallow text features, the webscraping R6 contract) -- the estate's one text-extraction ruler, COMPOSED and not re-implemented -- and it is VOCABULARY-FREE, so it catches walls in languages and phrasings nobody listed. Markers only NAME the family afterwards. A marker-first design would convict every article that mentions cookies or a sign-in link, which is exactly the false-positive class that cost nx_mirrorintegrity a 941-permil FP rate on real data. ABSTAIN, NEVER ACQUIT: an unreadable file and a zero-length body return UNPROVEN, never CONTENT. license_tier: ORIGINAL No hw writes (Rule 26). LIB (no main).