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.

docs/deployment/topology-guide.md

@@ -191,6 +191,19 @@ are carried across:
 - **Seeding is idempotent** (`ON CONFLICT DO NOTHING`), so a row that already has a genuine version
   keeps it and no snapshot is flagged. Booting with baselining on every start is free after the
   first.
+- **The flag is per-table as of LocalDb 0.3.0.** Turning replication on for the first time still
+  seeds all ten tables at once, so the flagged set is every registered table and the pair exchanges
+  an ordinary full snapshot — that part is unchanged, so a site whose `site_events` table is at its
+  1 GB cap should still be purged before the first enable, and one slow first sync expected. What
+  changes is every *later* edit: adding an eleventh table to
+  `SiteLocalDbSetup.ReplicatedTables` on a site that is already replicating now snapshots that one
+  table, where through 0.2.x the single per-database flag re-streamed all eleven in full, in both
+  directions at once. Upgrading a replicating pair to 0.3.0 in place is a no-op for this: the ten
+  tables are already ledgered, so nothing seeds and nothing is flagged.
+- **Mixed 0.2.x/0.3.0 versions still sync.** Scoped snapshots are negotiated per session by
+  capability, and a peer that does not advertise it is sent a full snapshot — so the pin bump does
+  not have to be simultaneous for replication's sake. (It still has to be simultaneous for the
+  stop-and-start-together rule below, which is a separate constraint.)
 
 Turning replication back **OFF** is likewise a both-nodes change: deregistration must be symmetric,
 because the sync handshake compares the two nodes' registered-table digests fail-closed — a node