test(site): pin the active-node notification-config purge; scope the guarded write

Task 12 + Task 13. No production behaviour change in either.

Task 12: DeploymentManagerActor.HandleDeployArtifacts already purges
notification_lists and smtp_configurations on every artifact apply, but nothing
pinned the actor's CALL to it — ArtifactStorageTests covers the storage method
only. Task 15 deletes SiteReplicationActor's copy, making this the sole
remaining call site, and Task 16 edits this actor's wiring; dropping the call
would leave plaintext SMTP passwords on disk with every suite still green.
Verified red-first by commenting the call out: the pin fails with that message.

Task 13: StoreDeployedConfigIfNewerAsync STAYS. Re-verified both callers —
SiteReplicationActor:375 (dies at Task 15) and SiteReconciliationActor:166
(survives). Reconciliation is a per-node startup self-heal against central
whose fetch races real deploys, so the deployed_at guard still does real work
there. Doc comment rewritten to say so, and to warn against porting the guard
onto the replication path where it would fight the HLC rather than help it.
Also corrected a stale 'guarded standby write' section header in the tests.

Re-ran the Task 13 step 2 scope check: ConfigFetchRetryCount's only production
reader remains SiteReplicationActor:157, so its option + validator rule stay
until Task 17, after Task 15 deletes the actor.

Verified: build 0 warnings; SiteRuntime 533, Host 329, StoreAndForward 153,
LocalDb integration 16 — all pass.

Claude-Session: https://claude.ai/code/session_01BL2Vu1ESDQ9SCN4gVKkdts

src/ZB.MOM.WW.ScadaBridge.SiteRuntime/Persistence/SiteStorageService.cs

@@ -156,9 +156,22 @@ public class SiteStorageService
     /// clause so the guard is atomic with no application-level read-modify-write.
     /// </summary>
     /// <remarks>
-    /// This is the standby-node write path for replicated configs.  The active-node
-    /// apply path (<see cref="StoreDeployedConfigAsync"/>) remains unguarded and always
-    /// overwrites, because the active node's write is always authoritative.
+    /// <b>This is the reconciliation write path.</b>  <c>SiteReconciliationActor</c> runs a
+    /// per-node startup self-heal against central: it asks central what this node should be
+    /// running and fetches anything missing.  That fetch races real deploys, so the
+    /// <c>deployed_at</c> guard is what stops a slow reconcile response from overwriting a
+    /// newer config that landed while it was in flight.  The active-node apply path
+    /// (<see cref="StoreDeployedConfigAsync"/>) remains unguarded and always overwrites,
+    /// because a deploy is always authoritative.
+    /// <para>
+    /// It was originally the <i>standby</i> write path as well, under notify-and-fetch: the
+    /// standby was told a deploy had happened and fetched the config itself.  LocalDb Phase 2
+    /// replaced that with change-data-capture — the config row simply replicates — so the
+    /// standby no longer writes here at all, and last-writer-wins on the primary key (not
+    /// this guard) is what orders concurrent writes between the two nodes.  Reconciliation is
+    /// the reason the method survives; do not port the <c>deployed_at</c> guard onto the
+    /// replication path, where it would fight the HLC rather than help it.
+    /// </para>
     /// <para>
     /// <paramref name="deployedAtOverride"/> is exposed for testing so that the exact
     /// <c>deployed_at</c> value can be controlled without sleeping between calls.