docs(plans): close residual #2 (R1 merged, LocalDb 0.3.0); register rows 41-42 (LocalDb test flake, push.sh publish-bug family check)

docs/plans/2026-08-15-arch-review-remediation-execution-log.md

@@ -101,10 +101,18 @@ Deliberately not fixed in this program — each has a stated reason, not an over
    set the residual called for, and `_subscriptionIds.Count`), so no accumulated counter exists to
    drift; this also closes the connection-level-failure case that let resolved climb above total.
    Regression tests: `TagResolutionCounts_*` in `DataConnectionActorBatchTests`.
-2. **Per-table `needs_snapshot` in LocalDb.** Baselining one table currently re-streams every
-   registered table in both directions. Narrowing it needs an on-disk schema change LocalDb 0.2.1
-   deliberately avoided (wire/schema compatibility). Documented as a follow-up in the library's
-   own README and `RegisterReplicated` remarks.
+2. ~~**Per-table `needs_snapshot` in LocalDb.**~~ **RESOLVED 2026-08-15 (LocalDb 0.3.0, scadaproj
+   `cea3930`; ScadaBridge pin bump `a5ac309a`, R1).** Bookkeeping schema v3 adds
+   `__localdb_snapshot_state` (per-table flags); the database-wide flag survives by design for
+   whole-oplog events (cap prune, impossible ack). Wire-compatible by capability negotiation, not
+   a version bump: `Handshake.supports_partial_snapshot` + `SnapshotBegin.tables` (empty = all) +
+   `SnapshotAck` on the unbounded control lane — a peer that doesn't advertise gets a FULL
+   snapshot, which is *required* (an old receiver advances its watermark to the snapshot's as-of
+   and would silently discard un-included tables' deltas). A partial snapshot moves no watermark
+   on either side; debt clears on receiver ack (crash-safe), clear-on-enqueue kept for old peers.
+   Library suite 199/199 incl. old-peer interop; ScadaBridge Host 490/490 on the bump. Adding an
+   eleventh table to `ReplicatedTables` on a replicating site now snapshots ONE table instead of
+   re-streaming all, both directions.
 3. **Event batching per proto message.** Individual `AttributeValueChanged`/`AlarmStateChanged`
    events still ride one gRPC message each; batching them is a new wire shape (proto + both
    client/server), deferred rather than folded into this program's additive-only changes.