nx_https_fetch_file.nx

nx_https_fetch_file.nx -- SOVEREIGN LARGE-ARTIFACT FETCH: stream an https response BODY straight to a file, in CONSTANT memory. Why this exists (2026-08-01). nx_https_get buffers the WHOLE response into one sys_mmap(HGC_OUTCAP) and then CORRECTLY refuses anything past it with NX_HTTPS_GC_BUF_OVERFLOW (surfaced to the CLI as code=8). That 4 MiB ceiling made every dataset, model weight, corpus and media artifact unreachable by sovereign fetch -- it is what blocked an 11MB standard CIF test sequence from media.xiph.org, and through that the whole ffmpeg-oracle BD-rate measurement (debt 1785634091). The fix is NOT to raise the constant. A per-fetch 256MB mmap is the memfloor incident waiting to happen (nx_skullsdf took 27.7GB and froze every seat's builds); raising a cap only moves the landmine. nx_https_get_stream ALREADY streams decrypted record plaintext to a dest_fd incrementally -- buffered append via gs_bufapp, Content-Length body_target, redirect following, Range support -- and it is gate-proven by nx_https_fetch_lib_gate and used in anger by the media vault. It was simply never exposed as a general CLI. So this WIRES THE PRIMITIVE THAT ALREADY EXISTS rather than building a second one. Usage: nx_https_fetch_file <url> <outpath> -> writes the response BODY (headers stripped, redirects followed by hf_fetch_to_file) to outpath. Prints: NX-HTTPS-FETCH-FILE url= out= status= bytes= verdict=OK|FAIL Exit: 0 ok / 2 usage-or-bad-url / 3 store-or-connect / 4 tls / 5 http / 6 cannot-open-outpath Deliberately NO connect-host:port override: that exists for our own domains and would mean copying hgc_parse_ipport verbatim (rule 15). Add it by EXTRACTING the shared parser if a caller ever needs it. license_tier: ORIGINAL