nx_wpt_acquire_lib.nx

nx_wpt_acquire_lib.nx -- LIB: BR21, the BYTE-PRESERVING half of WPT corpus ingest. WHY THIS EXISTS. On 2026-08-26 the corpus behind every BR1 number published on 08-18/19 was found banked NOWHERE. Two directories were recovered BY HAND and both reproduced their 08-18 corpus_sha exactly -- so the numbers were sound and the METHOD was not, and it failed in two different ways: FIDELITY: the hand path re-emits every body through a TEXT TOOL ARGUMENT. A text argument is a NUL-terminated C string. html/syntax/parsing-html-fragments is the ENCODING-DETECTION suite and the-input-byte-stream-003.html is UTF-16LE with a BOM, i.e. a file whose FOURTH BYTE IS NUL. Transcribing it through any C-string carrier truncates it at byte 3 and the corruption is SILENT. SCALE: dom/nodes is 178 files, and a partial dom/nodes is a SAMPLE, which may never be published as a population fact. This lib is the half that can be proven offline: parse the declared manifest, verify a body against BOTH numbers upstream publishes for it, write RAW BYTES with an explicit length, and read them back and compare. Nothing here consults a NUL in file content -- every content path carries its length. THE VERIFICATION IS NOT OURS AND THAT IS THE POINT. GitHub's contents API declares, per file, a size and a sha. That sha is the GIT BLOB OBJECT NAME -- sha1 over "blob " + decimal_length + NUL + content -- which nx_swhid_lib already computes and which was proven this session against NINE vectors produced by git 2.49.0, an INDEPENDENT implementation. So a single flipped byte anywhere in our transport is caught by a hash WE DID NOT CHOOSE AND CANNOT INFLUENCE. Size alone would not do it: a byte swap preserves length. The blob sha alone would not do it either -- it is derived from the length, so a check that trusts our own count of the bytes is partly checking itself. Both, or neither. license_tier: ORIGINAL