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

docs/known-issues/2026-06-26-deploy-config-exceeds-akka-frame-size.md

@@ -22,11 +22,17 @@ The central→site hop is unchanged — it still sends a small `RefreshDeploymen
 still fetches over HTTP, so that half of the original fix stands.
 
 **The successor ceiling is different in kind.** The gRPC sync stream has a 4 MB default receive
-limit, and LocalDb batches by ROW COUNT (`LocalDb:Replication:MaxBatchSize`, default 500), not by
-bytes. A ~70 KB `config_json` — the largest measured in production — times 500 rows is ~35 MB,
-which would exceed the limit. The rig therefore pins `MaxBatchSize` to **16** (~1.1 MB worst case).
-Any deployment replicating wide rows must size that key deliberately; see the Phase 2 plan (D6) and
-`docs/plans/2026-07-19-localdb-phase2-live-gate.md`.
+limit. Until LocalDb 0.2.0 the library batched by ROW COUNT only (`LocalDb:Replication:MaxBatchSize`,
+default 500): a ~70 KB `config_json` — the largest measured in production — times 500 rows is
+~35 MB, which would exceed the limit, so the rig pinned `MaxBatchSize` to **16** (~1.1 MB worst
+case). See the Phase 2 plan (D6) and `docs/plans/2026-07-19-localdb-phase2-live-gate.md`.
+
+**Closed by LocalDb 0.2.0** (arch-review WP3.3): batching is now bounded by
+`LocalDb:Replication:MaxBatchBytes` — summed serialized bytes, default **2 MB**, sized under the
+4 MB limit — with the row count demoted to a secondary cap, and a single row above the budget sent
+alone rather than stalling the stream. The rig's `MaxBatchSize = 16` pin is retired and both keys
+are left at their defaults; a deployment replicating wide rows no longer has to size a row count
+against its widest column by hand.
 
 Note the failure mode differs from the one documented below: an oversized gRPC message is
 **rejected**, not silently dropped.