docs+log(siteeventlogging): explain the site_events purge oplog-backlog burst (R7)

The daily site_events retention purge (and the storage-cap trim) is CDC-captured
on a replication-enabled site node exactly like any other write — correct by
design, since LocalDb Phase 2 deliberately has no purge-exemption path — so the
backlog jumps by the deleted batch size at purge time. LocalDbOplogBacklog /
localdb_oplog_depth spike, drain, and an operator watching the gauge with no
context reads it as a replication fault.

Documentation + one log line, no behaviour change:

- topology-guide.md gains "Reading the replication backlog — the daily
  site_events purge burst": when it fires (PurgeInterval 24h, anchored to the
  active node's PROCESS START, not a wall-clock hour, so it moves after every
  failover), where it shows (replicated nodes only — not rig site-b/site-c),
  the healthy signature (LocalDbReplicationConnected stays true, backlog
  returns to ~0) and what a genuine fault looks like instead.
- Component-SiteEventLogging.md Storage records the same under retention/purge;
  Component-HealthMonitoring.md gains the two previously-undocumented
  LocalDbReplicationConnected / LocalDbOplogBacklog metric rows carrying the
  caveat, with cross-references both ways.
- EventLogPurgeService emits one Information line naming the row count and the
  expected transient backlog when a purge deleted rows on a replication-enabled
  node, so the spike is correlatable in the log. Replication-awareness comes in
  as a Host-supplied SiteEventLogReplicationCheck delegate, mirroring the
  existing SiteEventLogActiveNodeCheck seam: SiteLocalDbSetup.ReplicationIsConfigured
  goes internal so the PeerAddress-OR-ApiKey rule stays in one place and
  SiteEventLogging never learns to read LocalDb config. Unregistered ⇒ no note,
  matching the default that replication is opt-in and off.

Both delete paths carry the note (a cap trim is usually the larger burst); the
predicate is try/caught since a log-wording check must never break the purge.

Tests: 5 new EventLogPurgeServiceTests cases (replicated logs it, unreplicated
does not, zero-rows does not, cap purge logs it, throwing predicate still purges
and swallows) via a local capturing ILogger. SiteEventLogging 81/81 green,
Host 490/490 green, full solution build clean (0 warnings).

docs/deployment/topology-guide.md

@@ -198,6 +198,50 @@ that drops a table its peer still replicates stops syncing with a schema-mismatc
 diverging silently. Turning it on again later re-baselines, which is what makes the ledger prune on
 deregistration safe.
 
+#### Reading the replication backlog — the daily `site_events` purge burst
+
+The site health report carries `LocalDbReplicationConnected` and `LocalDbOplogBacklog` (nullable —
+**null means "no reading", not "disconnected with an empty backlog"**), and the same numbers export
+as the `localdb_*` Prometheus series (`localdb_oplog_depth` is the backlog gauge). A healthy pair
+sits at a backlog of roughly zero, so a sudden spike naturally reads as a replication problem.
+
+**One expected spike is not a problem: the daily `site_events` retention purge.** `site_events` is
+one of the ten replicated tables, and its retention DELETE is captured by CDC exactly like an
+ordinary write — by design, since LocalDb Phase 2 there is deliberately no purge-exemption path
+(the same property that makes a mass DELETE dangerous, which is why `ReplaceAllAsync` was deleted
+rather than reinstated). One oplog row is therefore queued per deleted event, and the backlog jumps
+by the size of the day's expired batch.
+
+- **When.** Every `ScadaBridge:SiteEventLog:PurgeInterval` (default **24 h**), plus once at
+  startup. The timer is anchored to the **active node's process start**, not to a wall-clock hour,
+  so the burst lands at a different time of day after each failover or restart — do not expect it
+  at a fixed hour. The storage-cap trim (default 1 GB) can produce the same shape off-schedule, and
+  is usually the larger of the two.
+- **Where it shows.** Only on a node with replication configured — the rig's site-a. site-b/site-c
+  have no capture triggers at all and report no backlog for a purge.
+- **What healthy looks like.** `LocalDbReplicationConnected` stays **true** across the spike, and
+  the backlog drains back to ~0 as the peer acks the batch — within seconds to a couple of minutes
+  depending on batch size (delta messages are bounded by `LocalDb:Replication:MaxBatchBytes`,
+  default 2 MB, and secondarily by `MaxBatchSize`). No dead letters, no schema-mismatch errors.
+- **What is actually wrong.** `LocalDbReplicationConnected` **false** while the backlog climbs, a
+  backlog that keeps rising across successive readings rather than draining, or a backlog that
+  never returns near zero between bursts. Those point at the sync stream — an ApiKey mismatch
+  (fail-closed: the pair simply stops converging), an unreachable peer, or an asymmetric
+  registered-table set.
+
+**Correlating it in the log.** When a purge on a replication-enabled node actually deletes rows it
+logs an Information line next to the purge count:
+
+```
+Purged 41230 events older than 30 days
+Purged 41230 site_events rows on a replication-enabled node — a transient LocalDb oplog backlog
+is expected while the deletes replicate to the peer. It drains on its own;
+LocalDbReplicationConnected staying true with the backlog returning to ~0 is the healthy signature.
+```
+
+An unreplicated node logs only the first line. If a backlog spike has no such line near it in the
+active node's log, the purge is *not* the explanation and the spike is worth investigating.
+
 ### Site Pair Upgrades — stop and start BOTH nodes together
 
 **A rolling upgrade of a site pair, one node at a time, is no longer supported.** It worked while

docs/requirements/Component-HealthMonitoring.md

@@ -37,6 +37,8 @@ Site clusters (metric collection and reporting). Central cluster (aggregation an
 | `SiteAuditBacklog` | Audit Log (site) | Count of `Pending` rows in the site-local `AuditLog` plus oldest-pending-age plus on-disk bytes. A configurable threshold drives a Health dashboard warning on the affected site tile. |
 | `SiteAuditWriteFailures` | Audit Log (site) | Count of failed hot-path audit appends at the site since the last health report. |
 | `AuditRedactionFailure` | Audit Log (central) | Count of payload redactor errors (over-redacted payloads, safety-net hit) since the last interval. |
+| `LocalDbReplicationConnected` | Consolidated site LocalDb | Whether a peer sync session is currently running on this node. **Nullable — null means "no reading", not "disconnected".** Reported only by a node with replication configured. |
+| `LocalDbOplogBacklog` | Consolidated site LocalDb | Unacked oplog depth (Prometheus `localdb_oplog_depth`). **Nullable — null means "no reading", NOT "connected with an empty backlog"** (a failed poll rendered as 0 would report a pair that cannot read its own oplog as perfectly healthy). **Expected transient spikes:** the daily `site_events` retention purge and the storage-cap trim are CDC-captured like any other write, so the backlog jumps by the batch size at purge time and drains as the peer acks it — see `Component-SiteEventLogging.md` → Storage and `docs/deployment/topology-guide.md` → *Reading the replication backlog* for the healthy-versus-faulty signature. |
 
 ## Reporting Protocol
 
@@ -113,6 +115,7 @@ These tiles are **point-in-time** like the Notification Outbox and Site Call Aud
 - **Cluster Infrastructure (site)**: Provides node role status.
 - **Notification Outbox (central)**: Provides central-computed outbox KPIs — queue depth, stuck count, parked count — for the headline dashboard tiles.
 - **Site Call Audit (central)**: Provides central-computed cached-call KPIs — buffered count, parked count, failed/delivered (last interval), oldest pending age, stuck count — for the headline dashboard tiles.
+- **Site Event Logging (site)**: Provides `SiteEventLogWriteFailures`. Its daily retention purge and storage-cap trim are also the expected cause of transient `LocalDbOplogBacklog` spikes on a replicated node — see [Component-SiteEventLogging.md](Component-SiteEventLogging.md) → Storage.
 - **Audit Log (#23)**: Provides the site-reported `SiteAuditBacklog` / `SiteAuditWriteFailures` metrics (via the site health report) and the central-computed `AuditRedactionFailure` metric, plus the central audit-row rate feeding the **Audit** dashboard tile group (Audit volume, Audit error rate, Audit backlog).
 
 ## Interactions

docs/requirements/Component-SiteEventLogging.md

@@ -92,8 +92,27 @@ Each event entry contains:
   On a site pair running **without** replication configured (by deliberate choice, e.g. the
   rig's site-b/site-c), the log stays node-local and a failover does start it fresh — the
   documented trade of not configuring a peer, unchanged by this policy.
-- **Retention**: 30 days. A **daily background job** runs on the active node and deletes all events older than 30 days. Hard delete — no archival. (Today, retention/cap deletes on a replicated node are captured by CDC like any other write — see the Volume Policy section above for why this is a small residual cost now that per-run rows are off by default.)
+- **Retention**: 30 days. A **daily background job** runs on the active node and deletes all events older than 30 days. Hard delete — no archival. Deletes are sliced into bounded 1000-row batches per DELETE statement rather than one unbounded statement, so a large expired backlog does not hold the write lock (and every concurrent recorder flush) for the duration of the purge.
 - **Storage cap**: A configurable maximum database size (default: 1 GB) is enforced. If the storage cap is reached before the 30-day retention window, the oldest events are purged first. This prevents disk exhaustion from alarm storms, script failure loops, or connection flapping.
+- **Purge deletes are CDC-captured on a replicated site — the resulting backlog spike is expected.**
+  Retention and cap deletes are ordinary row changes on a replicated table; there is deliberately no
+  purge-exemption path (LocalDb Phase 2 — CDC does all three jobs, and a table-wide exemption is the
+  same mechanism that made `ReplaceAllAsync` unsafe). One oplog row is queued per deleted event, so
+  the site health report's `LocalDbOplogBacklog` (Prometheus `localdb_oplog_depth`) jumps by the size
+  of the batch at purge time and drains as the peer acks it. **Healthy signature:**
+  `LocalDbReplicationConnected` stays true across the spike and the backlog returns to ~0; a backlog
+  that keeps climbing, or climbs while `LocalDbReplicationConnected` is false, is a genuine
+  replication fault and not the purge. The purge logs an Information line naming the row count and
+  the expected transient backlog whenever it deletes rows on a replication-enabled node, so an
+  operator can correlate a spike with the purge that caused it — a spike with no such line nearby is
+  not the purge. Node-local wiring: the Host supplies the replication predicate
+  (`SiteLocalDbSetup.ReplicationIsConfigured` — the `PeerAddress`-OR-`ApiKey` rule) as
+  `SiteEventLogReplicationCheck`; this component never reads LocalDb configuration itself, and with
+  no predicate registered the note is suppressed. Operator detail —
+  including that the purge timer is anchored to the active node's process start, not a wall-clock
+  hour — is in `docs/deployment/topology-guide.md` → *Reading the replication backlog*. See also the
+  Volume Policy section above for why this residual cost is small now that per-run script rows are
+  off by default.
 
 ## Central Access
 
@@ -121,4 +140,4 @@ Each event entry contains:
 - **Communication Layer**: Receives remote queries from central and returns results.
 - **Central UI**: Site Event Log Viewer displays queried events.
 - **Store-and-Forward Engine**: Its notification path (the site→central forward of script-generated notifications) reports forward failures and long-buffered notifications as Notification-category events. Routine enqueue and forward-success events are deliberately not logged — central's authoritative `Notifications` table (owned by the Notification Outbox component) is the audit record of record; site-side logging covers only the in-transit blind spot when central is unreachable.
-- **Health Monitoring**: Script error rates and alarm evaluation error rates can be derived from event log data.
+- **Health Monitoring**: Script error rates and alarm evaluation error rates can be derived from event log data; this component also reports `SiteEventLogWriteFailures`, and its purge is the expected cause of the transient `LocalDbOplogBacklog` spikes described in [Component-HealthMonitoring.md](Component-HealthMonitoring.md) → Monitored Metrics.