Merge branch 'localdb-per-table-snapshot' — LocalDb 0.3.0 pin: per-table needs_snapshot baselining (residual #2 / R1)

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