[cryptskii]

What

Re-pins the beta root register (dsm::economic::register::BETA_ROOT_REGISTER_MEMBERS) to the five GCP members as they are now, after the fleet was reprovisioned on 2026-09-27.

Why

The live fleet ran a storage-node build from 2026-09-12 (before the node cut, #932). Every device identity publish got HTTP 415 on /api/v2/cells, so no identity could publish and a fresh install never left the intro screen. The storage node on main (schema version 2, #978) accepts only an empty database or one already at schema version 2; it migrates nothing. So each member was reprovisioned: a forensic pg_dump, then a fresh schema and the main f779cb8 image. On first boot into that fresh database each member minted a new register incarnation. By design an incarnation cannot be carried into a fresh register.

That moved the canonical set id from DN61X37… to 7GBBB51DM8XP433F6H896G4R88W6RJZATZ3CT0WTRAFZ2EHYZ9D0. Until this lands, a clean build from main cannot resolve the canonical set: every claim, publish and sync fails closed with "the canonical register set is not resolvable from the local catalog".

Change

• dsm/src/economic/register.rs: the five new (member, incarnation) pairs, each the value that member logged at its first boot.
• dsm_sdk/src/sdk/storage_set.rs: the golden tests now carry the logged Base32 renderings. They also carry the set id all five members logged after the restart, which Core re-derives from the pin. That is an external value, not one computed by the code under test (the_pinned_beta_set_id_is_the_one_every_provisioned_member_logged).
• Frontend storage fixtures: same values.

Nothing else hardcodes the incarnations. Every other consumer (lineage.rs, peer_lineage.rs, sofi/lineage.rs, the SDK test-node harness) reads the pin at runtime.

Verified

• make lint: exit 0.
• dsm lib (economic::register, sofi::lineage, economic::peer_lineage): 41/0.
• dsm integration: economic_lineage_register 15/0, economic_admission_lifecycle 12/0, economic_provenance_semantics 9/0.
• dsm_sdk lib (sdk::storage_set, node-backed handlers::faucet_flow_tests): 15/0.
• Frontend StorageNodePanels and storageStore suites: 11/0.
• Proven on real Android devices (4 devices against the reprovisioned fleet, APK = f779cb8 + this pin):
  • every identity published 5/5;
  • faucet 4 × 100 ERA;
  • six online ERA transfers, conserving 400 ERA;
  • relationship tips agree in both directions;
  • a receiver that was stopped recovered on relaunch;
  • a sender killed after commit replayed its frozen send exactly once.

The fleet itself: all five members run dsm-storage-node:f779cb872-cloud and log storage set configured: 5 members, id=7GBBB51D….

Not in this PR

The APK still ships a stale bundled CA (dsm_client/frontend/public/ca.crt) and an env config that names the retired Alibaba fleet. A default install therefore cannot reach the fleet without a pushed override. That is its own PR, which follows this one.