[P2-E8.3] Helm charts + operator documentation #37

Helm charts for a non-global synchronizer (single sequencer + mediator) and an operator runbook.

Acceptance criteria:

• A dedicated sync can be brought up from the charts and registered
• The operator docs cover riding out a global-synchronizer outage with the outage traffic allowance ([P2-E5.9] Operator-set outage traffic allowance (FR-3) #129, design in docs: record the FR-3 decision, an operator-set outage traffic allowance #142):
  • Members' runway. Without the allowance, a member runs only on its prepaid remainder, about one top-up. To hold about a day, the top-up amount has to be a day's usage while the interval stays short, for example a one-hour minTopupInterval with targetThroughput at 24 times the member's real rate. The validator's wallet then needs a day's traffic in CC at each top-up, since the funds check prices the whole amount.
  • Setting it. During an outage, add outage-traffic-allowance (bytes per member) to the sync operator app's config and restart the app. Each member with a purchase on record gets its purchased total plus the allowance. Size it from the members' rates and how long the outage may last; the operator's exposure is the allowance times the members (sizing table in docs: record the FR-3 decision, an operator-set outage traffic allowance #142). Setting a smaller value and restarting lowers the limits again.
  • While it's set. The app warns every few minutes. A warning that a purchase landed means the global synchronizer is back. Any restart while it's set, planned or not, gives each member the full allowance again on top of what it bought since.
  • Removing it. Once the global synchronizer is back, remove the setting and restart, optionally after a grace period so active members' purchases pay down their credit first. Each limit goes back to the purchased total. A member that used the allowance is refused until its next top-up buys the shortfall together with a normal top-up, so its wallet needs the CC for both.
  • Several organizations. Every operator sets, and later removes, the same value at about the same time. Nothing changes until a threshold of operators agree, and until then each app warns for every member whose limit hasn't landed.
  • Grants by hand. Every start of the app without the allowance sets limits back to the purchased totals, which takes back any traffic granted by hand above them.
• The operator docs say which existing metrics show the traffic path is healthy: the reconcile trigger's latency, iteration and completion metrics, and the sequencer's per-member purchased-traffic metric
• The operator docs say that nothing checks an operator's grants against purchases: the sequencer applies any traffic limit the operator sets, so a grant rests on trusting the operator, and Phase 2 accepts this ([P2-E9.6] User story: traffic purchase and transacting on a dedicated synchronizer #123 step 10, folded in from [P2-E8.11] Document that an operator can grant traffic nobody paid for #140)
• The validator release bundle carries the sequencer traffic dashboard a sync operator uses ([P2-E7.3] Operator metrics & dashboards #97, feat: Prometheus and Grafana for LocalNet canton-network/splice-multi-sync#62): canton-network/synchronizer-fees-sv.json is listed in cluster/pulumi/observability/grafana-dashboards/validator-dashboards.yaml. automations.json is already listed, and the SV bundle already carries both.

Epic: #71

Source: docs/planning/extending-mainnet-work-plan.md