feat: add chunk_byte_sizes to XorbReconstructionTerm, with a client opt-in

[XciD]

Summary

• Add an optional chunk_byte_sizes: Vec<u32> to XorbReconstructionTerm: the uncompressed size of each chunk of the term's range, in chunk order. It is skipped when empty, so the wire format does not change for clients that do not ask.
• Add client.reconstruction_chunk_byte_sizes (HF_XET_CLIENT_RECONSTRUCTION_CHUNK_BYTE_SIZES, off by default). When set, RemoteClient adds ?chunk_byte_sizes=true to its V1 and V2 reconstruction requests.
• The CAS server (huggingface-internal/xetcas#510) fills the field only when asked, and only for ranges up to 1 GiB.
• API note: api_changes/update_261004_reconstruction_chunk_byte_sizes.md.

Why

hf-mount (huggingface/hf-mount#246) reads files in bounded fetches of up to 32 MiB, one FileReconstructor each, and xet splits each fetch in 3 reconstruction queries (8 + 16 + 8 MiB). A sequential read therefore makes about 96 CAS queries per GiB (304 for a 3.09 GB file), where a single stream made 3 or 4 per file.

hf-mount already caches reconstruction plans (CachedXetClient) and can derive the plan of a sub-range from a cached plan, but without chunk sizes a derived plan keeps whole terms: up to a 64 MiB xorb range for a small read. With the sizes, the client trims terms at chunk boundaries as the server does. It can then ask for the plan of a window of up to 1 GiB once and derive the plan of each fetch in it locally: about 1 query per GiB instead of 96.

History

This was closed in March together with xetcas#510, over the size of the field (one value per chunk, about 16K per GiB of range) and the server memory for large ranges. xetcas#510 now lists the sizes only for ranges up to 1 GiB, and hf-mount would ask for windows within that limit.