chore(deps): bump ZB.MOM.WW.LocalDb to 0.3.0 — per-table snapshot resync

LocalDb 0.3.0 (scadaproj branch localdb-per-table-snapshot) narrows the
snapshot-resync flag from one per-database bit to one per table, closing the
residual 0.2.1 explicitly deferred. On-disk bookkeeping schema goes to v3
(__localdb_snapshot_state, upgraded in place on open); the wire stays compatible
with 0.1.x/0.2.x, negotiated by capability rather than by a lib_schema_version
bump — which is not available, since the handshake compares that field
fail-closed for equality.

SiteLocalDbSetup needed no restructuring: it already calls RegisterReplicated
once per table, which is exactly what per-table flagging keys off. The comment
now records that the loop shape is load-bearing, and what it buys — adding an
eleventh table to ReplicatedTables on an already-replicating site snapshots that
one table, where through 0.2.x the same edit re-streamed all eleven in full in
both directions. First boot is unchanged (all ten seed at once, so the flagged
set is every registered table and the library sends an ordinary full snapshot),
and upgrading the rig in place is a no-op (the ten are already ledgered, so
nothing seeds and nothing is flagged).

Suites: Host 490/490, SiteRuntime 604/604, StoreAndForward 134/134,
SiteEventLogging 76/76. Solution build clean.

topology-guide + CLAUDE.md LocalDb bullet updated; the umbrella scadaproj
CLAUDE.md travels in that repo's commit.

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

@@ -118,6 +118,17 @@ public static class SiteLocalDbSetup
             // to any genuine remote write of the same key and wins only where the peer has no
             // version at all. It is idempotent (ON CONFLICT DO NOTHING) and therefore free on
             // every boot after the first, which is why it is unconditional rather than a flag.
+            //
+            // The PER-TABLE loop is load-bearing as of LocalDb 0.3.0, not just tidy. The snapshot
+            // flag baselining raises is now per-table, and it is raised by the call that actually
+            // seeded something — so adding an ELEVENTH table to ReplicatedTables on an already
+            // replicating site now streams a snapshot of that one table, where through 0.2.x the
+            // flag was a single per-database bit and the same edit re-streamed all eleven in full,
+            // in both directions. Nothing about the first boot changes: enabling replication on a
+            // site that has been running without it seeds all ten at once, the flagged set is
+            // therefore every registered table, and the library sends that as an ordinary full
+            // snapshot. A hypothetical "register the whole list in one call" API would silently
+            // give the coarse behaviour back.
             foreach (var table in ReplicatedTables)
                 db.RegisterReplicated(table, baselineExistingRows: true);