docs(site-secrets): final-review doc fixes — replication prerequisite, upgrade impact, audit shape

I2: topology guide + Component-SiteRuntime + register row 127 state that a site pair using
deployed secrets must run LocalDb replication. I3: row 127 + topology guide state the upgrade
impact (whole artifact deploy fails and reads Out of date until referenced secrets exist
centrally). M6: audit row carries secrets/missing, no removed field; removal-only deploys write
no central row. M2/M3/I1 as-built notes; CLAUDE.md secrets bullet corrected.

docs/deployment/topology-guide.md

@@ -591,13 +591,33 @@ Component-SiteRuntime.md → *Deployed Secrets*.
   `deployed_secrets` table plus its **own** `DeployedSecretsMirror` running on its own schedule,
   `ScadaBridge:SiteRuntime:DeployedSecretsMirrorInterval` (default **15s**). A freshly-promoted
   standby is therefore current on secrets within one interval of the last deploy, not instantly.
-- **Rollout is a deployment record, not a code change** — see the deferred-work register for the
-  vd03/QA prerequisites (shared store provisioning, `Provider=SqlServer` on both centrals, the KEK
-  alignment check above, recreating any hand-seeded site secrets centrally, then *Deploy Artifacts*).
+- **A site pair that uses deployed secrets MUST run LocalDb replication** (`LocalDb:Replication:*`
+  configured on both nodes — see *Reading the replication backlog*). The standby's only path to the
+  secrets is the replicated `deployed_secrets` table. On an **unreplicated** pair only the node that
+  was active at deploy time holds the secrets; after a failover the new active node has **none**
+  (or a stale hand-seeded copy) until the next *Deploy Artifacts*, and a removal applied while one
+  node was active leaves the secret live on the other. The Artifacts badge still reads *Current* —
+  the stamp is per site, not per node. If a pair cannot be replicated, re-run *Deploy Artifacts*
+  after every failover.
+- **Secret rotation and live connections.** An artifact deploy writes and mirrors the shipped
+  secrets **before** it pushes data-connection definitions to the DCL, so a connection created or
+  reconfigured by the same deploy resolves a newly shipped secret on its first connect. A rotation
+  that leaves the connection's config unchanged does **not** recreate the connection (the push is
+  hash-guarded): the new value takes effect on that connection's **next (re)connect**.
+- **Rollout is a deployment record, not a code change** — see the deferred-work register (row 127)
+  for the vd03/QA prerequisites (shared store provisioning, `Provider=SqlServer` on both centrals,
+  the KEK alignment check above, LocalDb replication on every site pair that uses secrets,
+  recreating any hand-seeded site secrets centrally, then *Deploy Artifacts*).
+- **Upgrade impact — do the prerequisites in the same window as the upgrade.** Once a central runs
+  this build, any site whose data connections carry a `secret:` reference fails its **whole**
+  artifact deploy (shared scripts, external systems and DB connections included, not just secrets)
+  and its Artifacts badge reads *Out of date*, until every referenced secret exists in the central
+  store. Before upgrading an environment, check whether its connection configs use `secret:`
+  references and whether its site pairs run LocalDb replication.
 - **The gRPC secrets hub is retired in ScadaBridge** — `Secrets:Replication:Enabled` now fails
   startup on either role (Component-Host.md → *Secrets*). QA and vd03 currently run
-  `Replication:Enabled=false`, so upgrading them to a build carrying this change will not itself
-  fail fast.
+  `Replication:Enabled=false`, so the boot itself will not fail fast — the deploy-time impact above
+  is what bites.
 
 ## Scaling Guidelines