feat(localdb): create config + sf_messages tables in the consolidated DB

Task 7. SiteLocalDbSetup.OnReady now applies SiteStorageSchema and
StoreAndForwardSchema alongside the Phase 1 schemas, so the nine site
configuration tables and the store-and-forward buffer live in the
consolidated LocalDb file.

Deliberately NOT registered for replication. The bespoke SiteReplicationActor
and the StoreAndForward ReplicationService still own these tables until the
Task 14 cutover deletes both and registers them in one commit; registering
early would run two replicators over the same rows and let either one's
defects hide behind the other's writes.

Pinned by two tests through the real composition root: one asserting all
twelve tables exist, one asserting ReplicatedTables is EXACTLY the Phase 1
pair. Non-vacuity verified by removing the DDL and observing the failure.

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

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

@@ -1,7 +1,9 @@
 using Microsoft.Extensions.Configuration;
 using ZB.MOM.WW.LocalDb;
 using ZB.MOM.WW.ScadaBridge.SiteEventLogging;
+using ZB.MOM.WW.ScadaBridge.SiteRuntime.Persistence;
 using ZB.MOM.WW.ScadaBridge.SiteRuntime.Tracking;
+using ZB.MOM.WW.ScadaBridge.StoreAndForward;
 
 namespace ZB.MOM.WW.ScadaBridge.Host;
 
@@ -44,6 +46,12 @@ public static class SiteLocalDbSetup
         {
             OperationTrackingSchema.Apply(connection);
             SiteEventLogSchema.Apply(connection);
+
+            // Phase 2: the site's configuration tables and the store-and-forward buffer
+            // now live in this file too. Created here, deliberately NOT registered — see
+            // below.
+            SiteStorageSchema.Apply(connection);
+            StoreAndForwardSchema.Apply(connection);
         }
 
         // Both tables qualify: each has an explicit primary key (RegisterReplicated
@@ -52,6 +60,13 @@ public static class SiteLocalDbSetup
         db.RegisterReplicated("OperationTracking");
         db.RegisterReplicated("site_events");
 
+        // The Phase 2 tables are created above but NOT registered yet. The bespoke
+        // SiteReplicationActor / StoreAndForward ReplicationService still own replicating
+        // them until the Task 14 cutover deletes both and registers these in one commit.
+        // Registering them now would mean two independent replicators writing the same
+        // rows — harmless in principle (both upsert) but it would mask a defect in either
+        // one, which is exactly what the cutover needs to be able to see.
+
         // AFTER registration, so migrated rows enter the oplog and reach the peer like
         // any other write. Before it, they would be invisible to replication forever.
         SiteLocalDbLegacyMigrator.Migrate(db, config);