feat(ccb): a storage set commits which register histories it trusts, not just which nodes

[cryptskii]

Item B of the locked order, implementing both decisions exactly as you specified them: 0x0002 schema 3 with paired entries, and the incarnation checked on reads and claim acceptance.

The fact being committed

A set of bare node ids says only which nodes a vault trusts. A member that lost and rebuilt its register still satisfies that — it owns the same identity key and the same configured id — and can then assert "no claim here" for a cell the real incarnation once held. Nothing distinguishes it, because owning the identity was the whole test.

A set entry is now the pair:

entry = CCB(member_id, register_incarnation_id)
entries sorted strictly by member_id
duplicate member_id forbidden, regardless of incarnation_id
storage_set_id = H_dom(DSM/storage-set, CCB(entries))

So the set id commits not to which nodes, but to which durable register histories on those nodes.

Sorting is by member_id alone, never by the pair — sorting on the whole entry would let one member appear twice under two incarnations and still produce a strictly ascending list, which is the exact ambiguity this removes. There is a named test for that case.

Schema bumps, and why two

0x0002 goes 2 → 3. 0x0001 (VaultStateV2) goes 3 → 4, because the registry's own §2.7 rule is that nesting is by complete CCB including the nested schema version, so a nested bump propagates upward whether or not the enclosing field list moved. Both superseded pairs are burned; a_nested_schema_bump_changes_the_enclosing_encoding is the control that would have caught skipping it.

Set ids and vault-state commitments therefore change. That is the reprovision you accepted, and it is the point.

Where the incarnation comes from

A node generates it once, from the OS random source, into a write-once row in its own database, committed durably. It is deliberately not derivable from the signing key, the node id, or any seed — a node that kept its identity key but lost its register database must come back different, because that is the fact a vault needs.

Startup refuses when [[storage_set.members]] lists an incarnation for this node that its database does not hold. That is the rebuild made loud, at the one moment an operator is looking, instead of silent at read time.

Both directions bound, as you required

Reads — every answer carries x-dsm-register-incarnation, on the held and absent branches alike. Stamping only held would leave the dangerous case — a rebuilt member reporting emptiness — unmarked. The reader's decision is one function with the full matrix as its contract:

echoed	verdict
member A, incarnation X (committed)	may count
member A, incarnation Y	Unavailable
member B, incarnation X	Unavailable (attribution)
either half missing	Unavailable

An incarnation mismatch is Unavailable — never absence, never a value, and never an invalid-credit verdict. The node is not lying; it simply is no longer the member this vault committed.

Claims — the vault names a storage_set_id that is now a function of the pairs, and a node derives its own set id from its members including its own durable incarnation. A rebuilt member computes a different id and refuses the claim as foreign-set before any insert, so it cannot write into the old vault's register namespace and have the discontinuity surface only later on reads.

Root register

Per your ruling: core dsm stays config-free and keeps BETA_MEMBERS + quorum as the authority over which members; the catalog supplies each member's incarnation; RootRegisterProfile::derive_set_id re-derives the id from the candidate pairs and refuses any candidate whose membership is not the network's. Endpoints stay transport metadata and are not inputs. Both ProvenanceResolver and PeerEvidenceFetcher gained root_register_candidate_set, named "candidate" so no call site reads it as authority.

Discovery-added nodes get an empty incarnation deliberately, which fails the catalog closed — discovery can carry transport and can never mint set membership.

Open assumption

Your answer says the profile "commits storage_set_id". Core cannot compute that digest without incarnations, and pinning it as a literal needs a real provisioned value I will not invent. So the committed authority is currently membership + quorum in core, incarnations from the catalog, id re-derived and checked. If you want an additionally-pinned digest once the beta fleet is provisioned, that is a value you would hand me.

Mutation controls

Each restored with a verified tree stamp (git diff | shasum identical before and after).

mutation	named test that went red
duplicate member id no longer refused	invalid_inputs_are_refused_rather_than_normalized — the "one member under two incarnations" assertion
all-zero incarnation no longer refused	same test, its own assertion
the reader stops checking the incarnation half	only_the_committed_member_in_its_committed_incarnation_counts — on the SAME-NODE-REBUILT-REGISTER row
NodeStorageSet stops refusing a rebuilt incarnation	a_node_whose_register_was_rebuilt_refuses_to_serve_the_configured_set
the absent branch stops carrying the stamp	every_read_answer_names_the_register_incarnation_serving_it

Stated rather than claimed: the sort key — member id alone vs the whole pair — has no mutation control, because duplicates are the only input where the two orders differ and the duplicate refusal fires first. The load-bearing gate is that refusal, which is tested above. The sort is documented as belt-and-braces, not asserted as independently load-bearing.

Fleet bring-up is now two-phase

No generator can know an incarnation in advance, so generate_node_configs.sh no longer emits a member list and production.toml documents the sequence: boot with [storage_set] absent (register inactive, every claim refused — the correct state for a fleet that has not agreed on a set), collect each node's logged register incarnation for node <id>: <Base32-Crockford>, write the member list into every node config and the client env config, restart. A node whose configured incarnation is not the one its database holds refuses to start, so a mistake is loud.

The incarnation is established and logged unconditionally at startup, before any set is considered — establishing it only when a set exists would be a bootstrap that never starts.

Verification

Rust 1.98.0, the version rust-toolchain.toml declares.

• root make lint — exit 0
• workspace board --release -- --test-threads=1 — 3982 passed, 0 failed
• node board (SQLite, local-dev,strict) — 288 passed, 0 failed
• node board (Postgres 14, default features) — 258 passed, 0 failed
• production_safety_checks.sh (incl. TLA+), ci_scan.sh, no_clock_and_no_json.sh, check_forbidden_symbols.sh, codegen_enforce.sh — all exit 0

Dependent sweep, and a self-inflicted regression worth naming. Making register_incarnation a required config field broke 106 dsm_sdk tests — every fixture that writes a fleet TOML. The existing CLAUDE.md rule fires on capability removal; a newly-required field reads as an addition and removes exactly as much. A refinement candidate is filed to widen that trigger. A further 11 "failures" after the fix were my own error — I ran with --test-threads=4 when CLAUDE.md documents these suites share process-global singletons; serially they pass.