Make the S3 extension production-ready at million-object scale

[forhappy]

What changed

• keep commit-session authority stable across lease renewal while fencing real takeover
• add bounded streaming bulk ingestion, ordered publication, resumable checkpoints, and branch-aware traversal
• add tiny-object packs, exact live-byte inventory, sparse-pack candidates, pack-aware GC, and snapshot-safe repacking
• accelerate deep history, detached-commit listing, sparse diff/merge, persistent caching, fsck, and million-object traversal
• add cross-process maintenance barriers, writer fencing, durable GC checkpoints, and provider policy attestation
• enforce the large-object ownership boundary: Prolly stores one logical object as one final provider object and owns no upload IDs, parts, chunk manifests, or chunk GC
• expose a whole-object handoff so an external provider transfer manager can upload/resume, after which Prolly verifies and publishes the completed object

Why

The original benchmark work exposed correctness failures under authority renewal and severe request/byte amplification at bucket scale. Follow-up large-object work also crossed an architectural boundary by putting transfer-part lifecycle into Prolly. This PR keeps versioned repository metadata in Prolly, tiny-object packing as an explicit repository optimization, and transport multipart state entirely with the provider uploader.

Validation

• full prolly-s3-core all-target/all-feature test suite
• full prolly-s3-client all-target/all-feature test suite
• live RustFS 65 MiB single-PutObject stream gate
• live RustFS 33 MiB external-upload handoff across commit-session restart
• 10K/20K correctness and performance gates plus 100K/500K/1M metadata qualification recorded in the performance envelope

The ignored AWS qualification and scale gates still require an operator-owned real bucket and explicit SLO configuration.