PoC: registration lifecycle (offboard vote + reporting-state wiring)

[timwu20]

Daml PoC, stacked on the reward-reporting rung (#8). Completes the registration story create-to-offboard: the offboard vote requested in review (#1 thread), plus the production wiring for the reporting state. Reworked per review: the vote archives only the registration.

What this does

• DsoRules_ArchiveSynchronizerRegistration (new choice, vote-dispatched via appended SRARC_ArchiveSynchronizerRegistration): archives the RegisteredSynchronizer. Archiving the registration alone shuts down everything that matters: traffic can no longer be bought (the buy choice needs the registration disclosed to it), and rewards can no longer be processed (PoC: extension reward reporting + expansion (Daml) #8's start-processing choice requires the live registration). It is also the recovery path for a duplicate registration that slips past the SV-UI uniqueness check.
• Registration now creates the reporting state: DsoRules_RegisterSynchronizer creates the DedicatedSynchronizerState alongside the registration and returns both cids, so an operator can report from its first round (production wiring for PoC: extension reward reporting + expansion (Daml) #8's report flow, following its assumption 2).

Offboarding semantics (design position)

The vote archives the registration and nothing else. The reporting state is deliberately left alone, for a reason found in review: every report replaces the state contract with a new contract id, and a vote pins exact contract ids when it is created. Votes stay open for days. If the operator files one routine report while the offboard vote is open, the pinned id goes stale and the vote fails when it closes — so a vote that touches the state hands the operator a way to block its own offboarding indefinitely. Keeping the state out of the vote removes that lever.

The leftover state is harmless. The operator can still file reports against it, but a report can never be turned into Amulet: minting requires the start-processing choice, and that choice requires the live registration, which is gone. Cleanup is simple: the state is DSO-signed, so DSO automation archives it any time after the offboard — and if a report has changed the id in the meantime, the archive just retries against the current one. Nothing else is waiting on it.

One ordering rule: clean up the old state before re-registering the same synchronizer. Re-registration creates a fresh state that starts with no reporting history, and if the old state were still around, the operator would hold two live states and could report the same round twice. Per-report processing votes remain the backstop either way.

Deliberately untouched by offboarding: MemberTraffic records (history) and reward processing already authorized for past rounds (ProcessRewardsV2 contracts complete) — authorized work finishes, new work stops.

How it's verified (Daml Script)

• test_RegisterSynchronizer_viaVote (extended): registration creates the reporting state.
• test_ArchiveSynchronizerRegistration_viaVote: register then offboard via 4-SV votes; the registration is gone, the state survives, the operator can still file a report — and the report is worthless (the processing gate is pinned by test_StartProcessing_registrationGate in PoC: extension reward reporting + expansion (Daml) #8) — then DSO-side cleanup archives the state.
• TestExtensionRewardVote (updated): reports against the vote-created state instead of a test-created one.

Full amulet, wallet, and dso-governance suites pass.

Tracked in

Implements E1-4 (ChainSafe/canton-extending-mainnet#30); the SV-UI duplicate check that pairs with this as the uniqueness mechanism is #54.

[sadiq1971]

Some comments from my side

[moritzkiefer-da]

thx