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).

src/ZB.MOM.WW.ScadaBridge.SiteEventLogging/ServiceCollectionExtensions.cs

@@ -30,11 +30,18 @@ public static class ServiceCollectionExtensions
         // it unregistered, and the purge defaults to "always run" (the
         // pre-fix behaviour). Building the service via a factory so the
         // optional delegate flows from DI rather than the constructor default.
+        //
+        // SiteEventLogReplicationCheck flows the same way and is likewise Host-supplied:
+        // it only selects the wording of the purge log line (whether to add the
+        // "expect a transient LocalDb oplog backlog" note), and this component has no
+        // view of LocalDb:Replication. Unregistered ⇒ no note, matching the default
+        // that replication is opt-in and off.
         services.AddHostedService(sp => new EventLogPurgeService(
             sp.GetRequiredService<SiteEventLogger>(),
             sp.GetRequiredService<IOptions<SiteEventLogOptions>>(),
             sp.GetRequiredService<ILogger<EventLogPurgeService>>(),
-            sp.GetService<SiteEventLogActiveNodeCheck>()));
+            sp.GetService<SiteEventLogActiveNodeCheck>(),
+            sp.GetService<SiteEventLogReplicationCheck>()));
         return services;
     }