perf(siteeventlog): pace the site_events purge burst — per-tick delete ceiling + accelerated catch-up (row 34)

Measured the unbounded purge burst and found it can force a full ten-table
snapshot resync, then bounded it. No purge-exemption path was added — the
deletes are still CDC-captured like any other write, which stays ruled out
by design; what changed is how many a single tick performs.

MEASURED (harness: real EventLogPurgeService over a real LocalDb file with
site_events genuinely RegisterReplicated, plus a two-node loopback gRPC
replication pair; docker rig untouched):

  393 bytes/row incl. indexes => a 1 GB event log holds ~2,731,947 rows.
  Expiring all of them in ONE tick:  285 s, 2,731,947 oplog rows,
  284 MB oplog payload, 2.73 M row-version tombstones (7-day retention),
  i.e. 2.7x LocalDb's MaxOplogRows default of 1,000,000. Crossing that makes
  the 60 s maintenance tick prune the oplog and set needs_snapshot — a FULL
  snapshot of all ten replicated tables, bought by a routine retention purge.

  The resident backlog is produced-minus-drained, so a healthy peer blunts it:
  on loopback the same burst peaked at 391,424 and cleared in 6.0 min. That is
  the problem, not the reassurance — the old safety margin was a function of
  peer throughput and vanished with the peer down. A bounded tick is safe at
  any peer speed.

  Drain is not a bottleneck: 7.6k-19.8k tombstones/s (20k / 500k / 2.73M runs).

SHIPPED:
  - SiteEventLogOptions.MaxPurgedRowsPerTick (default 250,000; 0 = unlimited
    escape hatch, negatives rejected). One SHARED budget across the retention
    purge and the cap trim — two independently-capped phases would let a tick
    emit twice the intended burst. 4x margin under MaxOplogRows, which is also
    shared with every other replicated table's ordinary traffic.
  - SiteEventLogOptions.PurgeCatchUpInterval (default 5 min, validated > 0 and
    <= PurgeInterval). Without it pacing would make retention converge in 11
    DAYS at the daily cadence; with it the worst case converges in ~11 ticks
    (~55 min), every burst bounded. 5 min rather than 1 so ticks cannot outrun
    the peer's drain and re-accumulate the backlog.
  - A ceiling is claimed only when work genuinely remains (bounded EXISTS probe),
    so an expired set landing exactly on the budget does not arm a no-op retry.
  - Visibility: rate-limited (15 min) Warning naming the ceiling and the
    accelerated interval, plus an unthrottled counter
    scadabridge.site.event_log.purge_ceiling_hits — its SHAPE distinguishes a
    backlog converging from a site whose event rate outruns one paced tick.
  - The purge loop is a delay loop rather than a PeriodicTimer, so its cadence
    now anchors to the END of the previous purge. Documented.

ROW-33 INTERPLAY VERIFIED: pacing lowers each spike and lengthens total purge
duration, but a full 250k tick drains in ~23 s (~4 min even at 10x a real
link's penalty) against the 15-minute sustained dwell and a 5-minute gap to
the next tick. The UNPACED 2.73M burst had only 2.5x of margin (6.0 min), so
pacing makes the badge assumption robust rather than merely preserving it.

Docs travel together: Component-SiteEventLogging.md, topology-guide.md
("Reading the replication backlog" + the row-33 badge note), CLAUDE.md's
purge-burst sentence, and a dated measurement/decision note under docs/plans/.

Fail-before: the new behavioural tests do not compile against the pre-fix
service (RunPurge was void); with PurgeBudget neutralised to always-unlimited,
6 of the new tests fail and all 19 pre-existing ones pass.

Tests: SiteEventLogging 93/93, Commons 715/715, HealthMonitoring 115/115,
Host 505/505. Solution build clean.

docs/requirements/Component-SiteEventLogging.md

@@ -94,12 +94,35 @@ Each event entry contains:
   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. 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.
+- **Per-tick delete ceiling** (`MaxPurgedRowsPerTick`, default **250 000**; `0` = unlimited): one
+  purge tick deletes at most this many rows, **shared** by the retention purge and the storage-cap
+  trim — two independently-capped phases would let a tick emit twice the intended burst. A tick that
+  stops at the ceiling schedules the next tick after `PurgeCatchUpInterval` (default **5 minutes**)
+  instead of `PurgeInterval`, so retention still converges: a worst-case backlog drains over
+  ~11 accelerated ticks (≈55 minutes) rather than 11 days at the daily cadence, with every
+  individual burst bounded. The ceiling exists because the purge is CDC-captured (next bullet) and
+  an unbounded tick could exceed LocalDb's oplog budget; measured evidence and the chosen defaults
+  are in `docs/plans/2026-08-15-site-events-purge-burst-measurement.md`. A ceiling-limited tick logs
+  a Warning (rate-limited to one line per 15 minutes) and increments
+  `scadabridge.site.event_log.purge_ceiling_hits` — the counter is the unthrottled series that
+  distinguishes a backlog converging from a site whose event rate outruns one paced tick.
+  Consequence of the accelerated retry: the purge loop is a delay loop, not a `PeriodicTimer`, so
+  the cadence is anchored to the **end** of the previous purge rather than to process start.
 - **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:**
+  of the batch at purge time and drains as the peer acks it. **The height of that jump is bounded by
+  `MaxPurgedRowsPerTick`, not by how much history expired** — measured (register row 34): a full 1 GB
+  event log holds ~2.73 million rows at 393 bytes/row, and purging it unbounded queued 2 731 947
+  oplog rows, **2.7x LocalDb's `MaxOplogRows` default of 1 000 000**, which would make the
+  maintenance tick prune the oplog and flag a full ten-table snapshot resync. How much of that is
+  *resident* depends on the peer — the oplog drains concurrently, and a loopback peer held the same
+  burst to a 391 000 peak — so the overrun is conditional on peer throughput and unconditional when
+  the peer is down. Bounding the tick is what makes the outcome independent of the peer. Pacing the
+  tick, not exempting the purge from capture, is the fix — the exemption remains ruled out.
+  **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