[forhappy]

RustFS qualification: Both deletion orderings now pass after deleting the entire source checkout. Full/control/paged views use fresh Git runtimes, compare every Git object body with the native Git oracle, and verify the original native file hash directly from origin shards/xorbs. The live run executed the exact opt-in test (1 passed), made 528 S3 requests and reported no proxy errors; all source guards stayed unchanged. This is a small-fixture correctness gate, not 10 GiB or GC acceptance.

Shared receive could acknowledge a new branch that borrowed another ref's visibility closure, then acknowledge deletion of that source. If the deletion sorted before the borrower during canonical replay, a full reader could no longer open the acknowledged state.

New refs and explicit cross-ref bases now carry complete replacement evidence copied from their captured proof. The graph fast path remains; same-ref additive updates remain additive. This matches the CLI's new-ref policy and removes the writer's dependence on another mutable ref surviving replay. Metadata reconciliation and full-body ordering also clear deleted closures when a deletion has no visibility payload. Dictionary/physical retention never grants visibility by itself.

Stacked on #609; incorporates #600's replay/checkpoint characterization and a fixture stability repair. The final scope includes shared receive and readers because the reader-only candidate was insufficient. No new format, configuration, compatibility reader, or dependency override is introduced. The advisor plan and both excluded benchmark reports remain absent.

Validation

• Before the writer fix: native Git plus shared prepare/upload/commit acknowledged both creation and deletion; full reopen failed with cyclic/non-extending ref history. Control/paged modes were not reached after that failure.
• After the fix: deletion after branch acknowledgement and deletion after branch preparation but before commit both pass. Full/control/paged readers reopen and return the complete object closure enumerated by native Git. Supported reviewed-plan identities force the adverse transaction ordering.
• Release preparation target: 8 passed, two opt-in live tests ignored by the normal run. The new live test was then run explicitly against RustFS and passed both deletion orderings. Combined read/write capsule tests pass. Strict all-target Clippy for the primary crab-remote crate and formatting pass. Source guards remain unchanged.
• Full dependency lint is not green: unchanged integration-base crab-remote-git::commit_graph::Graph triggers large_enum_variant. The failed run is preserved; primary-only lint does not close that gap.

Evidence map and design

HTTP publication calls shared preparation. plan_visibility proves the captured prior closure; preparation owns its durable encoding. CLI capsule publication already uses replacement evidence for new refs. Complete/control/paged reconciliation share deletion semantics, with existing tests for inherited bases, removed objects, missing evidence and checkpoint precedence. The low-level borrowing codec remains expressive; regular shared publication no longer emits a mutable cross-ref dependency. Current main lacks this capsule reconciliation module; the failing baseline is the unmerged integration stack.

Is this the best fix? Closure ownership must be fixed at publication as well as deletion reconciliation. Copying a proven closure avoids another graph walk and prevents a mutable lifetime from entering durable evidence. It adds output-sized work for new aliases; authenticated immutable closure reuse remains a performance follow-up, not a reason to retain the unsafe dependency.

Draft, not merge-ready. Native regression evidence includes in-memory and RustFS origin stores. Maintenance/GC, complete dependency lint, fresh official install, the final six-case 10 GiB matrix, and hosted-S3 latency remain required. This is not a completed performance or lifecycle qualification.