[forhappy]

Prepared residual reads returned every requested decoded chunk from a source xorb at once, even when the Git packer supplied a small batch budget. Keep one verified serialized source in the staging read plan and return bounded, independently owned decoded batches. Switch the existing Git packer to the bounded method.

Pin source descriptors before queuing workers. The plan retains each worker handle and buffered result, so cancelling a read cannot lose chunks; resuming with smaller limits splits the queued output to the new budget. Worker-owned activity accounting closes on every worker exit. Shared source and chunk helpers retain full size, raw BLAKE3, logical xorb, footer-payload and decoded-chunk verification.

The public complete-source read_next API is present in release tag v1.2.4 (76977b2af19) and current main. Preserve that contract, sharing the same integrity checks; canonical consumers migrate to read_next_bounded. Removing the released method requires a breaking library release. No dependency, format, schema, configuration or lockfile changes.

Stacked on #598. The separate capsule incremental-upload change will consume this reader as well; it is not included here.

Validation on 51b7d6956e8:

• Four focused real-filesystem/SQLite tests pass: complete-source compatibility; bounded/owned batches and early-drop/reopen; changed-body rejection; and queued-read cancellation with pathname unlink and a smaller resumed budget.
• During implementation, the cancellation test first reproduced an empty resumed stream; the tighter-budget regression then reproduced two returned chunks against a one-chunk limit. Final regressions pass without weakening either assertion.
• Strict release all-target staging Clippy, formatting and the production CLI library consumer check pass. All 2,646 guarded inputs remain unchanged through verification.
• The refactor moves existing coalesced reading into its owner module. Non-test growth pays for a retained encoded-source cursor, owned pending work and bounded buffered output. Returned batches do not retain old source allocations.

Fresh native-CLI RustFS qualification on dependent combined commit 4a9b8059d4e passed 75 commands / 57 checks: two 64 MiB entropy files, four versions through alternating native/Git staging, no second full local payload, retired published staging owners, eight independent cold byte oracles and full remote integrity. New xorb bytes per version were 67,156,162 / 2,216,454 / 2,284,332 / 2,354,458. Source and CLI hashes stayed unchanged. This is component E2E proof, not the final 10 GiB matrix.

Evidence map: PushPipeline::xorbs calls the staging read plan after mark_staging_push_reader_if_needed / snapshot_staging_recipes_if_needed pin selected recipe leases. SQLite temporary rows select canonical segment/prepared authority; file descriptors are pinned before worker admission. load_prepared_source and decode_prepared_chunk share the existing Xet parser checks with ordinary staged reads and the released complete-source API. Tokio 1.53.1 documents awaiting &mut JoinHandle as cancellation safe; storing that handle preserves the queued result. Existing publication/retirement ordering is unchanged. Current main retains the complete-source behavior rather than this bounded cursor.

Is this the best fix? Staging owns source grouping, byte verification and reader lifetime. Keeping pending work and bounded output there avoids separate caller caches or integrity readers. The explicit released API is the reason the full-source method remains.

Remaining gates: native CLI and cross-platform qualification for this exact change, and the larger initiative's final-source matrix/lifecycle/hosted-S3 gates. The earlier 10 GiB recovery evidence predates this change and is not claimed for it. This draft is not ready to merge. Both excluded benchmark reports and the advisor plan are absent.