chore(deps): LocalDb 0.2.0 — dereg cleanup, late-opt-in baselining, byte-budget replication

docker/site-a-node-b/appsettings.Site.json

@@ -97,12 +97,15 @@
       "ApiKey": "dev-site-a-localdb-sync-key",
       // ---- Phase 2 sizing, from the Task 1 rig soak (not from the defaults) ----
       //
-      // MaxBatchSize (default 500) is a ROW count, not a byte budget, so the batch
-      // size in bytes is set by the widest replicated column. That is
-      // deployed_configurations.config_json: ~721 B on this rig, but up to ~60-70 KB
-      // in production (measured, Task 1) - and 70 KB x 500 is ~35 MB against gRPC's
-      // 4 MB default receive limit. 16 keeps a worst-case batch near 1.1 MB.
-      "MaxBatchSize": 16,
+      // The MaxBatchSize = 16 pin is RETIRED as of LocalDb 0.2.0 (arch-review WP3.3).
+      // It existed only as a hand-computed proxy for a byte budget: batching was
+      // row-count-only, and 70 KB of production config_json x the 500 default is
+      // ~35 MB against gRPC's 4 MB receive limit. The library now bounds a batch by
+      // MaxBatchBytes (default 2 MB of summed serialized size), with the row count
+      // demoted to a secondary cap, so both are left at their defaults here - a
+      // deliberately unset MaxBatchBytes is the 2 MB default, and the widest row no
+      // longer has to be guessed at deploy time.
+      //
       // Backlog caps bound the oplog while the peer is offline. Exceeding them is
       // NOT data loss: the oplog is pruned to the ceiling and needs_snapshot is set,
       // so the peer catches up by snapshot resync instead of incrementally. That