[cryptskii]

The three reviewed correctness fixes for the DLV close stack, replayed onto main.

#676, #677 and #678 merged at their pre-fix heads (d4a12311, bac58261, 429f4e20) while these commits were still local, so main currently carries the stack without them. Each commit is the one written and verified against its original branch. One conflict was resolved on replay, in storage_node_sdk.rs: main now has #677's MemberClaimResult additions surrounding the dead impl KeyedPutFanout this deletes. main's content kept, the dead impl deleted.

What is currently wrong on main

A superseded artifact row is replayed over the newer one. republish_unpublished_artifacts selects a batch before it makes a single network call, and every iteration below that awaits. A close committing in that window supersedes a row already in the batch and publishes its own bytes under the same .../latest mirror key. Replaying the stale row afterwards puts an older generation back on every member, and the damage is permanent and invisible: upsert_artifact_publication_state declines to write to a superseded row, so nothing records that the fleet disagrees with us, and list_unpublished_artifacts skips published rows, so the newer bytes are never re-sent. A closed vault would serve its birth anchor to every trader, indefinitely.

The existing a_superseded_generation_is_never_swept cannot catch this: its SELECT already filters superseded rows, so it passes whether or not the pass re-checks anything. republish_rows is split out so a test can be handed a deliberately stale batch, which is exactly what the real pass holds after its own SELECT.

One acceptance path counts without attribution. A member answering Refused while naming our own digest as the value it holds is holding our bytes, and that arm counted it without asking who answered. It was the only acceptance path skipping the check its siblings apply. Quorum means a majority of DISTINCT members hold these exact bytes, so a node replying under another's id contributes twice to a majority that does not exist. Refusals stay unattributed deliberately: counting one makes the claim fail closed as Contested, so it can only make us more conservative.

The claim envelope has two durable homes. SPHINCS+ signing here is deterministic, so a rebuilt claim is byte-identical to a replayed one, and nothing on the wire, in a digest or in a test can tell which happened. FrozenClaimEnvelope makes the machinery absent rather than merely unused: one constructor, load, reading already-retained bytes, and claim_settlement_slot accepts nothing else. resume_close_intents holds no signing key at all, asking can_sign() instead, with the commit half moved to finish_prepared_close. dlv_close_intent.claim_bytes is dropped, column included, leaving settlement_slot_claim_local as the single home.

Schema note: CLIENT_DB_SCHEMA_VERSION = 5 was introduced by this stack and no v5 database has shipped, so reshaping it here owes no bump.

Mutation controls

Guard disabled	Test	Result
stale-row re-read removed	a_row_superseded_after_selection_is_not_replayed_over_the_newer_one	red, the stale row republishes
attribution check dropped	a_refusal_holding_our_own_digest_still_needs_attribution	red, accepted: 2 of 3, one node counted twice
envelope rebuilt from bytes	n/a	does not compile, E0308

The attribution fix previously had no test at all. The new one needed a fake-fleet knob for the refusal phrasing, because the current node never emits that shape, which is the reason the arm cannot be taken on trust.

Local gate

• cargo fmt --all -- --check clean
• cargo clippy --all-targets -- -D warnings clean
• cargo test -p dsm_sdk --lib full suite, result posted below

[cryptskii]

Full suite on the replayed branch: 1797 passed, 0 failed, 7 ignored, 597s. cargo fmt --all -- --check and cargo clippy --all-targets -- -D warnings both clean.

That is the whole dsm_sdk lib suite against the merged main, not a filtered subset — the three fixes and everything the stack landed, together.