[P2-E1.4] Registry uniqueness

DA review on fork PR #2 settled the enforcement mechanism: **off-ledger, in the SV voting UI**, rather than the consume-once registry contract originally proposed here. Registrations are vote-gated, so the UI warns/blocks a `RegisterSynchronizer` vote request when an active registration already exists for that synchronizer id. Operator rotation is out of scope entirely (a new operator means a new synchronizer), which removes the stale-registration-after-handover path. Recovery for a duplicate that slips through (e.g., two vote requests in flight): archive one via the registration-lifecycle vote (#30). The on-ledger merge assert (operator consistency, fork PR #2) stays as the backstop that keeps a duplicate visible instead of silently blending records.

**Key files:** SV frontend vote-request flow (`apps/sv/frontend`), vote-request review UI

**Acceptance criteria:**
- [ ] Creating a `RegisterSynchronizer` vote request for an already-registered synchronizer id surfaces a duplicate warning in the SV UI
- [ ] Recovery path exercised: a duplicate registration can be archived by vote (#30)

**Depends on:** E1-1, E1-4 (#30)

**Epic:** ChainSafe/canton-extending-mainnet#13

_Source: re-scoped 2026-07-29 from the consume-once registry proposal, per DA review on canton-network/splice-multi-sync#2._

Start in apps/sv/frontend and trace the RegisterSynchronizer vote-request flow into the vote-request review UI. Check the existing registration-lifecycle vote (#30) path and dependencies E1-1/E1-4; done means duplicate active IDs warn or block and a duplicate can be archived through vote #30.

Written by the indexing model from the issue text.