[forhappy]

A readback-required immutable write returned a corruption error after its first wrong hash response, while ordinary verified reads already applied the shared one-retry corruption policy. This could abort large-file publication even when the stored origin bytes were healthy. The #598 fresh 10 GiB run exposed a readback digest failure; direct origin/local bytes matched afterward and a diagnostic retry audited 161 matching bodies. The cause of that original response remains unresolved.

Route exact immutable-write readback through the existing bounded verifier. Logical creates use the same private verifier and retain both ETag and version from the response whose bytes passed verification. Only GET is retried; the acknowledged PUT is not replayed. Persistent corruption still fails under the existing FatalAfterOneRetry rule. Checksum-qualified creates, occupied logical keys, byte ceilings and source-error propagation keep their existing contracts. Production hash-verification duplication is reduced.

Stacked on #598, independently of the opening/format work. No wire format, public API, retry option or dependency changes.

Validation on 5c58a939d6c:

• The new single-corrupt-readback regression failed before the production change. Its base storage module is byte-identical on Integrate indexed catalogs, staging and lifecycle #598 and the temporary opening branch used for that reproduction.
• 223 storage tests pass; the existing ambient-S3 signed-read test remains ignored because its external credentials were not selected. No assertion or ignore is weakened.
• Strict all-target storage Clippy, formatting, whitespace checks and a release-library build pass. Guarded source bytes remain unchanged.
• A release-linked API probe against real RustFS tests exact/logical immutable creates with 64 MiB bodies. One corrupt response must recover; two corrupt responses must fail. Each case must issue exactly one PUT and two GETs, then independently recover the original bytes from origin. All four rebased-source cases pass, with exact origin SHA-256 matches after each case and the successful logical receipt matching the verified GET ETag. The probe and every guarded source input remain unchanged.

Evidence map: CLI Xet publication, shared preparation and protected dependency publication call the logical-create API; capsule/shard/checkpoint/source-root publication calls exact verified create. crab-storage owns provider I/O, bounded framing, hash verification and retry classification. verified_body shares the standalone verifier’s policy and binds the accepted response identity. Current main already applies that corruption retry to ordinary verification; these newer immutable-create APIs live in the integration stack. Streaming size/hash verification uses the same retry class and is unchanged. Existing tests cover qualified checksums, different valid occupied encodings, staged routing, bounded/streamed reads and operation-bound identities.

Is this the best fix? Reuse the existing verification owner instead of adding retries to each publisher, replaying PUTs, relaxing hashes or exposing another setting. Returning the verified GET identity is necessary for logical creates; standalone verification discards only that extra identity.

This is a component recovery fix, not a completed 10 GiB matrix. Fresh full-matrix, larger lifecycle/performance qualification and the rest of the indexed-remote initiative remain required. The advisor plan and both excluded large-file audit reports are absent from this two-file diff.