nx_content_get.nx

nx_content_get.nx -- CHUNKED CONTENT DOWNLOAD SOURCE: the sovereign door for NAS->laptop bytes. WHY THIS EXISTS (operator standing order 2026-09-03: "dont build python ... build nishi and nishi estate should have this capability and if it doesnt lets build from the first byte up these capabilities"). nx_content_put calls itself "the sovereign door for laptop->NAS bytes" and there was NO MIRROR. Measured the same day: a NAS-side source that had legitimately diverged from its laptop twin could not be brought back without a seat retyping 38,414 bytes through a chat transcript -- which is the hand-transcription defect this estate builds organs to avoid. The absence was named as a gap before it was built; this is it. nx_content_get begin <src> -> CG-BEGIN src= total_bytes= sha256= chunk_raw= nchunks= nx_content_get chunk <src> <index> -> CG-CHUNK OK ... chunk_sha256= b64=<data> nx_content_get probe -> the derived chunk size and every term of its derivation IT IS A MIRROR, NOT A COPY, AND THE ASYMMETRIES ARE THE DESIGN: 1. STATELESS BY CONSTRUCTION. nx_content_put needs staging, an index and a stale-reaper because the bytes ACCUMULATE ON THE RECEIVER. In a get they accumulate on the CLIENT, so there is no server-side transfer state to stage, index, resume or reap. Half of the incumbent machinery is therefore deliberately ABSENT rather than mirrored -- carrying it would be complexity with no invariant to protect, and a reaper with nothing to reap is a beat that can only ever be wrong. 2. THE GENERATION CHECK REPLACES CAS. The incumbent refuses a DIFFERENT body for an index that already landed, so a blind retry can never corrupt. A get has the opposite exposure: the SOURCE can change under a multi-call read, and reassembling chunks from two generations yields a franken-file that is byte-valid and semantically nonsense. So begin declares the WHOLE-FILE sha256 and the client MUST verify its reassembly against it. A file edited mid-transfer fails that check loudly. Per-chunk sha is carried too, and here is exactly what each can and cannot do: the per-chunk digest detects a CORRUPTED chunk, and it CANNOT detect a consistent read of a CHANGED file. Only the whole-file digest can, which is why begin pays one full read to compute it. A SIZE COMPARISON WOULD NOT DO: a same-size rewrite passes it, and "size is never an identity" is a law this estate has been bitten by three separate times. 3. THE CHUNK SIZE IS DERIVED FROM THE *RESPONSE* CAP, NOT THE REQUEST CAP. This is the term a symmetric copy would get wrong. The incumbent sizes its chunk against the 65,536-byte request-body cap it measured at the edge; a get rides the RESPONSE path, whose observed capture cap is 163,840 -- the bound nx_fs prints as capture_cap when it truncates. Reserve = the receipt skeleton MEASURED FROM THE LITERAL AT RUNTIME, never hand-counted, plus a full path, plus the digits and hex digest it carries. The raw size is floored to a multiple of 3 so base64 never emits interior padding. MEASURED 2026-09-03: reserve=1249 (66+1024+95+64), chunk_raw=121941, exactly divisible by 3.