docs(plans): close residual #9 (R7 merged); register rows 33-34 for R7's findings (oplog backlog observability, purge-burst pacing)

docs/plans/2026-08-15-arch-review-remediation-execution-log.md

@@ -131,11 +131,17 @@ Deliberately not fixed in this program — each has a stated reason, not an over
    are central-cluster/browser concerns outside this harness and remain open scope.
 8. **Playwright 14 pre-existing env failures.** Present on `main` too, rig-state related, not
    introduced by this branch.
-9. **`site_events` retention purge still oplog-visible.** WP3.2's sliced retention DELETE is a row
-   change like any other and is captured by CDC on a replicated site (site-a) — correct per the
-   "CDC does all three jobs" design (no separate resync path to gate), but means a purge burst is
-   visible in the oplog/backlog metrics; not a correctness issue, just a metrics-reading note for
-   operators watching `LocalDbOplogBacklog` during a purge window.
+9. ~~**`site_events` retention purge still oplog-visible.**~~ **RESOLVED 2026-08-15 (documented
+   by design, `9d2834e3`, R7).** The CDC capture of retention/cap deletes is correct and unchanged
+   — there is deliberately no purge-exemption path. The operator-facing gap is closed three ways:
+   `docs/deployment/topology-guide.md` → *Reading the replication backlog* (burst shape, 24 h
+   cadence anchored to active-node process start, healthy-vs-faulty signature),
+   `Component-SiteEventLogging.md` → Storage, and `Component-HealthMonitoring.md`, which gained
+   the two previously-undocumented `LocalDbReplicationConnected`/`LocalDbOplogBacklog` metric
+   rows. `EventLogPurgeService` now emits one Information line correlating the spike to the purge
+   on a replication-enabled node (both the retention and the storage-cap delete paths), via a
+   Host-supplied `SiteEventLogReplicationCheck` delegate sourced from the single
+   `SiteLocalDbSetup.ReplicationIsConfigured` predicate. No behavior change; 5 unit tests.
 
 ## Docs propagated