set CHUNK_SIZE to 1300 — empirical max at eclevel=25 is 1386B, not 3200B as spec claimed

@@ -154,16 +154,16 @@154154 /**155155  * Bytes of binary data per chunk. Each chunk becomes one Aztec code.156156  *157- * 3200 bytes base64url-encodes to ~4267 chars; combined with the JSON envelope158- * overhead (~100 chars) the printed text is ~4367 chars — well under the159- * bwip-js limit of 4999 chars at eclevel=25. DO NOT increase without re-running160- * a bwip-js capacity test for the densest envelope.157+ * Empirical cap at AZTEC_ECC_PERCENT=25 is ~1386 bytes (envelope ~1945 chars)158+ * — beyond that bwip-js reports `aztecNoValidSymbol: Maximum length exceeded`.159+ * 1300 leaves headroom for envelope-overhead drift (larger index/total fields160+ * as page counts grow). DO NOT raise without re-probing bwip-js: encode a161+ * full-entropy envelope and confirm it still renders.161162  *162- * Sized to drive a typical vault down to ~6 A4 pages instead of ~24. Old163- * Codexes printed with a smaller chunk size still restore — the erasure163+ * Old Codexes printed with a smaller chunk size still restore — the erasure164164  * decoder derives shard size from the scanned chunks, not from this constant.165165  */166-export const CHUNK_SIZE = 3200;166+export const CHUNK_SIZE = 1300;167167 168168 /**169169  * Number of parity shards. With 2 parity shards, the Codex survives the loss