Ship a safe 1.0 operations starter pack and bounded support snapshot

## Outcome

An operator can monitor, alert on, and safely diagnose the supported Registry Stack 1.0 topology using maintained product contracts and a bounded support snapshot that does not expose secrets, subject data, source contents, or private configuration.

Institutional monitoring, retention, alert routing, incident response, and SLO ownership remain external.

## Scope

Provide:

- maintained Prometheus alert examples for readiness, repeated source refresh failure, audit-shipping acknowledgement, PostgreSQL unavailability, signer degradation, consultation failure, overload, and sustained 5xx behavior;
- one baseline dashboard or equivalent machine-readable dashboard source for the stable metrics contract;
- a documented distinction between liveness, readiness, freshness, correctness, backup freshness, and end-to-end availability;
- a one-command support snapshot with shareable and restricted tiers;
- stable, value-free diagnostic codes and a manifest describing every collected item, sensitivity, size bound, and intended consumer; and
- an operator journey from alert to safe inspection, mitigation, escalation, and evidence capture.

The support snapshot must use already-redacted product interfaces. It must not scrape arbitrary files or environment state.

## Security requirements

The default shareable tier must exclude:

- environment values and secret references;
- tokens, keys, PINs, credentials, hashes derived from identifiers, and raw headers;
- source rows, fixture bodies, claim values, subject identifiers, and audit records;
- raw runtime configuration, filesystem paths, private hostnames, and unbounded logs; and
- high-cardinality request or country-specific values.

Restricted output must be explicit, separately authorized, independently size-bounded, and never silently included in the default archive.

## Definition of Done

- [ ] Alert and dashboard artifacts validate against the released metrics contract.
- [ ] CI exercises alert expressions against representative healthy, degraded, and failed samples.
- [ ] The support command produces a deterministic manifest and bounded archive from a synthetic deployment.
- [ ] Adversarial tests seed secrets and subject-like values across env, config, paths, logs, errors, and fixtures and prove they do not enter default output.
- [ ] Output truncation, missing components, permission failures, and partial collection are explicit and non-fatal where safe.
- [ ] Documentation states that green readiness does not prove backup freshness, successful restore, source correctness, or an institutional SLO.
- [ ] A fresh operator can diagnose at least startup failure, stale Relay data, unavailable PostgreSQL, signer degradation, and incompatible Relay/Notary configuration using only shipped material.

## Non-goals

- Shipping or operating Prometheus, Grafana, a log platform, a SIEM, or an incident-management service.
- Product-defined institutional SLO values.
- Including raw audit evidence in a normal support archive.

## Related work

- #196
- #203
- #315
- #496

Start by reading related issues #196, #203, #315, and #496, then identify the released metrics contract and existing diagnostic or support-command entry points. Map the alert, dashboard, bounded snapshot, manifest, adversarial-test, and operator-documentation requirements to existing project areas; done means all Definition of Done checks pass without exposing restricted data.

Written by the indexing model from the issue text.