docs(site-secrets): document secret_mirror_status and standby mirror failures on the health report (M1)

docs/plans/2026-09-28-site-secrets-artifact-deploy-design.md

@@ -242,6 +242,15 @@ accurate as the spec:
     central row**; removals are logged on the site by `DeployedSecretsMirror`.
   - *Deployment prerequisite:* a site pair using deployed secrets must run LocalDb replication
     (topology guide), since on an unreplicated pair only the node active at deploy time gets them.
+- **Standby mirror failures reach central (follow-up, review finding M1).** A `DeployedSecretsMirror`
+  failure on the standby (e.g. a KEK mismatch) was only logged on that node — site health reports
+  are sent by the active node only. Each node now records its current failure set (names +
+  messages, never values) in a new, **12th LocalDb-replicated table `secret_mirror_status`** (one
+  row per node keyed by `node_name`), written only when the set changes plus once per start-up; a
+  per-node `SecretMirrorStatusReporter` puts every node's row on the active node's report as
+  `SiteHealthReport.SecretMirrorStatuses` (proto `SiteHealthReportDto` field 33, presence-wrapped),
+  and the Central UI health card shows a *Secret mirror failing* badge + per-node list. Requires
+  LocalDb replication for the standby's row to be visible, the same prerequisite as the secrets.
 - **Rig posture.** `docker/docker-compose.yml`'s central nodes now carry
   `Secrets__Store__Provider=SqlServer` plus a shared KEK; site-a shares that KEK (it is the
   secrets-via-artifact-deploy site); site-b/site-c deliberately carry a **mismatched** KEK so the