feat: fpz compressed pack format with batched GPU decode

[AlperenKonukbay]

Stacked on #31; once it merges this diff is fpz-only.

Format

pack_to_file(..., compress="fpz-bf16") stores bf16 macroblocks as split byte-planes: the mantissa plane raw (incompressible in practice), the sign/exponent plane zstd-compressed. 1.401x smaller on a real 38 GB transformer pack, byte-exact on read. The v2 layout splits the compressed plane into independent 16-byte-aligned chunks — the shape a batched GPU decoder needs. Opt-in; plain packs are unaffected. The encoder streams, so a 38 GB repack needs no uncompressed scratch file (50 min → ~3.5 min).

Read paths

• CPU decode: thread-pooled zstd (GIL released), any device target.
• GPU decode (FLASHPACK_FPZ_GPU_DECODE=1): ctypes bindings to libnvcomp's batched Zstd decompressor (_nvcomp_ll.py). The pybind nvcomp wrapper doesn't expose the batched C API and its per-chunk Python objects cost ~7x, so the batched path is the only GPU path shipped. Per batch: one pinned chunk table, one H2D copy, one foreign call — Python overhead independent of chunk count. Selection is automatic, with warn-once CPU fallback when libnvcomp is missing, the pack is v1, or its alignment doesn't satisfy the decompressor.
• fpz_gpu_warmup(): pays nvcomp's one-time CUDA module load off the hot path (worst observed 26.7 s lazy → ~1 s).

Measurements (38 GB pack, byte parity verified on every run)

leg	result
GPU decode, page-hot, H200	1.72–1.73 s (~22 GB/s logical)
GPU decode, page-hot, B200	1.78–1.85 s
NVMe-cold	decode 0.03 s — fully hidden under the reads
8× H200, rank0 fpz read + broadcast	2.02 s to all ranks

Stable across 5+ boots on 2 GPU classes (B200 is a single boot).

The default chunk size is now 1 MiB, matching the receipted configuration. It originally shipped at 64 KiB (nvcomp's default); a pre-merge regression gate (same-boot interleaved A/B, 38 GB pack) measured 64 KiB decoding 2.6x slower than 1 MiB on the threaded CPU path (39.5 vs 15.3 s hot — the path every consumer without the GPU extra gets) and 11% slower on the batched GPU path, for a compression-ratio difference under 1% (1.412x vs 1.401x). The same gate also live-verified the warn-once CPU fallback: with FLASHPACK_FPZ_GPU_DECODE=1 and libnvcomp absent, every read fell back cleanly with the install hint, parity intact. Trade-off: after an explicit page-cache drop, the fpz buffered refill can be slower than the raw path's O_DIRECT read on some nodes; the wire-cold tier still favors fpz on bytes moved. An O_DIRECT option for fpz reads is a natural follow-up.

nvidia-libnvcomp-cu12 lives in a separate fpz-gpu extra (NVIDIA-proprietary; kept out of default deps pending license review). 291 tests green.

[jfischoff]

Review by fal-9000 (GPT-5.6 Sol, xhigh) — reviewed at head 9601e5f4a9d88a6ee1f253eecf2d52782fa9b208, posted on the agent's behalf while its write access to this repo is being enabled (see FEA-8199).

Two blockers:

1. High — compressed artifacts still advertise flashpack_v4. Released v4 readers accept that footer but ignore fpz, then mmap the logical uncompressed length from compressed offsets. Depending on layout this fails late or silently reads compressed/adjacent/footer bytes as weights. Compressed packs need a new top-level format version so old readers fail closed, plus an old-reader compatibility test.

2. Medium — FPZ reads unconditionally call os.preadv, which is absent on Windows, while all FPZ tests are skipped there. The package advertises OS-independent support and runs Windows CI, so it can write an FPZ pack on Windows and then fail to read it. Keep the preadv fast-path and add a portable seek/read fallback, then run one Windows round-trip.