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

[timwu20]

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

What this does

• DsoRules_ArchiveSynchronizerRegistration (new choice, vote-dispatched via appended SRARC_ArchiveSynchronizerRegistration): archives a RegisteredSynchronizer and its DedicatedSynchronizerState in one governed action, validating that the state belongs to the registration. This 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, 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 — flagging for review)

Hard archive, no lifecycle-state field. Archival is the state: an archived registration cannot be disclosed, so the buy gate closes with no new checks anywhere; the archived state contract ends reporting the same way. Deliberately untouched: MemberTraffic records (history), and reward processing already authorized for past rounds (ProcessRewardsV2 contracts complete) — authorized work finishes, new work stops. A suspend-style status field stays addable later if wanted; it would put a new check into every reader, so it is not included here.

Two edges of this shape, named rather than found:

• A vote that passes optStateCid = None for a registration that has a state leaves that state active (Daml cannot check contract absence). No choice in this PR archives a state standalone; the cleanup path is the state's implicit signatory Archive exercised as the DSO party — the usual admin-archive precedent.
• Offboard-then-re-register starts a fresh reporting state (lastReportedRound = None), so rounds already reported under the old registration could be reported again. Processing stays vote-gated per report, which is the backstop; a re-registration vote can also carry the old high-water mark forward if the SVs prefer.

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; both contracts gone.
• test_ArchiveSynchronizerRegistration_mismatchedState: archiving with another synchronizer's state is rejected; the same exercise with the matching state then succeeds (positive control).
• test_ArchiveSynchronizerRegistration_duplicateSynchronizerId: two registrations sharing a synchronizer id under different operators (the duplicate-recovery scenario) — archiving one cannot take the other operator's state, so the state check matches on operator as well as synchronizer id.
• test_ArchiveSynchronizerRegistration_noState: a registration predating the reporting state offboards with optStateCid = None.
• 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.