test(localdb): port store-and-forward replication intents as CDC convergence specs

Task 10. Specifications first, deletion second: the bespoke ReplicationService
(explicit Add/Remove/Park/Requeue over Akka) dies at Task 14, so its behaviour
is restated here as outcomes the CDC replacement must still deliver. Written
in terms of ROWS, not operations — under CDC there is no Add or Park message to
observe, only a row that must end up right on both nodes.

Not ported: ReplicationOperations_AreDispatchedInIssueOrder. It asserts the
mechanism (inline fire-and-forget dispatch), and CDC capture is asynchronous
and batched by construction. Its portable content is the ordering OUTCOME —
add-then-remove must never converge to present — which is a test here, with
that reasoning recorded in the file so it does not read as an accidental drop.

DEVIATION: extracted the Phase 1 fixture into LocalDbSitePairHarness rather
than duplicating ~150 lines. Phase 1's tests now derive from it and still pass
unchanged. The harness registers the Phase 2 tables itself, since production
OnReady does not until Task 14; that method is marked for deletion at the
cutover, and the 8-table list is written literally so a cutover registering the
wrong set fails these tests instead of agreeing with itself.

Non-vacuity verified by unregistering sf_messages: 6 of 7 failed. The 7th —
the ordering test — PASSED, because an absent row is also what a pair that
replicates nothing looks like. Fixed with a control row that must converge in
the same window, so the absence is evidence rather than silence.

Also corrected two comments from Task 9 that claimed Task 14 makes
notification_lists/smtp_configurations replicated. It explicitly does not
register them, for the same reason the migrator skips them.

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

src/ZB.MOM.WW.ScadaBridge.Host/SiteLocalDbLegacyMigrator.cs

@@ -83,10 +83,16 @@ public static class SiteLocalDbLegacyMigrator
     /// <remarks>
     /// <b><c>notification_lists</c> and <c>smtp_configurations</c> are deliberately absent.</b>
     /// Both are purged on every deploy and are permanently empty by design — the site-side
-    /// write paths were removed on 2026-07-10. A pre-fix legacy file can still hold rows,
-    /// and <c>smtp_configurations.password</c> is plaintext, so migrating them would
-    /// resurrect plaintext SMTP passwords into a table that Task 14 makes REPLICATED. The
-    /// tables themselves are still created (see <c>SiteStorageSchema</c>); only their
+    /// write paths were removed on 2026-07-10. A pre-fix legacy file can still hold rows, and
+    /// <c>smtp_configurations.password</c> is plaintext.
+    /// <para>
+    /// Skipping them here is one half of a pair: the cutover also declines to register them
+    /// for replication, for the same reason. Migrating them would leave plaintext SMTP
+    /// passwords sitting in the consolidated database — one future <c>RegisterReplicated</c>
+    /// away from being shipped to a peer — in exchange for resurrecting config that nothing
+    /// reads. Keeping the tables permanently empty is what makes both decisions safe.
+    /// </para>
+    /// The tables themselves are still created (see <c>SiteStorageSchema</c>); only their
     /// historical contents are left behind.
     /// </remarks>
     internal static readonly LegacyTable[] SiteStorageTables =