fixed chunker: read directly into per-chunk buffers

[ThomasWaldmann]

Based on the copy-removal work of #10059 (now merged). Two commits:

1. ChunkerFixed reads via FileReader.readinto() into per-chunk buffers (one copy) instead of FileReader.read()'s bytearray-assembly + bytes() conversion (two copies).
2. FileReader.readinto() gets a fast path: without sparse processing and without an fmap (the normal case), the OS reads the file data directly into the caller's buffer (os.readv / the file object's readinto) - zero user-space copies, no per-block 1 MiB allocations, one syscall per chunk instead of one per block. This also covers the content-defined chunkers, whose fill() reads the scan buffer through the same method. Sparse/fmap readers keep the buffered path.

ChunkerFixed used FileReader.read(), which assembles each chunk in an intermediate bytearray (copying the data out of the reader's block buffers) and then converts it to bytes (copying everything again). Profiling a 20 GiB create with fixed,4194304 on an unencrypted repo showed chunkify as the single largest stage (29%), most of it these copies — the content-defined chunkers avoid both via their readinto path.

Now each chunk is read via FileReader.readinto() into a fresh per-chunk buffer: each byte is copied exactly once, from the reader's block buffer into the chunk, which is yielded as a memoryview over that buffer. All-zero detection happens at chunk granularity, like in the CDC chunkers.

Behavior notes:

• Chunk data stays valid after the iterator advances (per-chunk buffer, not reused) — same lifetime semantics as before; the reader/chunker interaction test verifies this.
• Ranges stemming from holes in sparse files are now reported as CH_ALLOC instead of CH_HOLE; downstream already treats both identically.

Measured (20 GiB, fixed,4194304, lz4, unencrypted repo, page-cache-warm, alternating runs, Apple Silicon): commit 1 on top of #10059 takes create from 29.35 s to 26.27 s (−10.5%), with chunkify self-time dropping 8.55 s → 6.73 s in the profile. Commit 2 adds another ~2-3% for the fixed chunker (the remaining user-space copy; what remains in chunkify now is the kernel's page-cache→buffer transfer); for the CDC chunkers its saved copy is below run-to-run noise, but the ~20000 avoided 1 MiB allocations and 4x fewer read syscalls per 20 GiB apply there too.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.64%. Comparing base (10fbb99) to head (8998a5a).
⚠️ Report is 3 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #10060      +/-   ##
==========================================
- Coverage   86.74%   86.64%   -0.10%     
==========================================
  Files          98       98              
  Lines       17085    17086       +1     
  Branches     2586     2585       -1     
==========================================
- Hits        14820    14804      -16     
- Misses       1571     1589      +18     
+ Partials      694      693       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.