chore(deps): bump Auth 0.2.1->0.3.0, LocalDb 0.2.1->0.3.4, MxGateway.Client/Contracts 0.2.0->0.2.1

Additive/wire-compatible releases across all three families; Directory.Packages.props
is the only pin surface (no csproj-level overrides, no lock files). Auth 0.3.0 adds
IApiKeyStoreMigrator and the optional Auth.ApiKeys.SqlServer package, neither needed
here. LocalDb 0.3.4's on-disk bookkeeping schema goes v2->v3 (upgrades in place on
open); 0.3.0 made the snapshot-resync flag per-table instead of per-database; 0.3.2
added validated Replication:KeepAlivePingDelay/KeepAlivePingTimeout config (defaults
60s/20s, left unset here) and a public LocalDbOplogGapException; 0.3.3 makes
RegisterReplicated throw LocalDbRegistrationException for a table that is the parent
of a row-mutating ON DELETE FK, which does not apply to this repo's four replicated
tables (no FKs). MxGateway.Client/Contracts 0.2.1 publishes the alarm snapshot_status
truncation frame and live alarm watch-list refresh; vendored the new nupkgs into
nuget-packages/ (the local-mxgw source MxGateway.* is exclusively package-source-mapped
to), matching the existing pattern from the 0.1.0->0.1.1 and 0.1.1->0.2.0 bumps.

Full solution builds clean (0 errors, 908 pre-existing analyzer warnings, unchanged
count). Full test suite: one failure, ClusterRoleInfoRoleLeaderCaseTests.
RoleLeaderChanged_for_driver_then_Driver_keeps_distinct_entries, reproduces
identically on the unbumped 0.2.1/0.2.1/0.2.0 tree under the same full-suite parallel
run (and passes standalone in isolation in 2s on the bumped tree) - a pre-existing
timing/parallelism flake, not a bump regression, so left as-is.

Updated CLAUDE.md and two docs (Configuration.md, operations/2026-07-20-localdb-pair-
replication.md) where they stated the old pin numbers and the now-superseded
per-database snapshot-resync behavior as current fact; dated historical records
(archreview snapshots, dated plan docs) were left untouched.

Claude-Session: https://claude.ai/code/session_01Wzg6NUCWHipSexLs2cgRFv

docs/Configuration.md

@@ -435,9 +435,9 @@ and syncs with nobody). A configured node registers all four tables with `baseli
 turning replication on converges the rows **already in the file** and not merely subsequent writes; an
 unconfigured node **deregisters** them at boot, dropping capture triggers an earlier build installed. ⚠️ The
 sync handshake compares registered-table digests **fail-closed**, so flipping either key is a
-both-nodes-together change: set it on both and restart both. On LocalDb 0.2.1 baselining flags a
-**per-database** snapshot resync (every registered table, in full, both directions), so trim a long-running
-`alarm_sf_events` buffer before enabling replication late.
+both-nodes-together change: set it on both and restart both. As of LocalDb 0.3.0 (this repo pins
+0.3.4) baselining flags a **per-table** snapshot resync — enabling replication on one table no
+longer forces a full-database resync of every registered table in both directions.
 
 Replication is **default-OFF** across the fleet; it is enabled per-pair as an opt-in. See
 [`docs/operations/2026-07-20-localdb-pair-replication.md`](operations/2026-07-20-localdb-pair-replication.md)

docs/operations/2026-07-20-localdb-pair-replication.md

@@ -77,12 +77,16 @@ Replication has two knobs, both under `LocalDb`:
 | `LocalDb:Replication:MaxBatchSize` | secondary row cap **and** the DB read-page size | `16` for the artifact cache. **Since LocalDb 0.2.0 this no longer bounds the wire message** — `MaxBatchBytes` does — so it is not the byte proxy the note here used to describe. Keep it at `16` anyway: `OplogStore`/`SnapshotStreamer` materialise a whole read page in memory *before* the byte-budget split runs, and 16 × ≈171 KB artifact chunk rows ≈ 2.7 MB bounds that transient allocation. Raising it no longer risks tripping the gRPC cap, only the allocation. |
 | `LocalDb:Replication:MaxBatchBytes` | primary cap on one outbound message (bytes) | Library default **2 MB**, sized under gRPC's 4 MB receive limit. Left unset on this rig. A single row over budget is sent alone rather than stalling the stream. |
 
-> **Library version.** This repo pins **`ZB.MOM.WW.LocalDb` / `.Replication` 0.2.1**
-> (`Directory.Packages.props`). The 0.1.3 → 0.2.1 move needed no config or code change here: the
-> wire protocol is unchanged (0.1.x peers still sync), and the on-disk bookkeeping schema v1 → v2
-> is upgraded **in place on open**, so an existing node's database file needs no operator action.
-> Two behaviours changed that an operator should know: batching is now byte-budgeted (the two rows
-> above), and **both of 0.2.x's lifecycle APIs are now used** (2026-08-18) — see the box below.
+> **Library version.** This repo pins **`ZB.MOM.WW.LocalDb` / `.Replication` 0.3.4**
+> (`Directory.Packages.props`; bumped from `0.2.1` on 2026-09-03, itself bumped from `0.1.3` on
+> 2026-08-15). Every move in that chain needed no config or code change here: the wire protocol is
+> unchanged end to end (0.1.x/0.2.x/0.3.x peers all still sync), and the on-disk bookkeeping schema
+> upgrades in place on open (now v3) with no operator action on an existing node's database file.
+> Behaviours worth knowing at the current pin: batching is byte-budgeted (the two rows above);
+> **both of 0.2.x's lifecycle APIs are now used** (2026-08-18, see the box below); the
+> snapshot-resync flag introduced by baselining is **per-table**, not per-database, since `0.3.0`;
+> and `0.3.2` added validated `Replication:KeepAlivePingDelay`/`KeepAlivePingTimeout` config
+> (defaults 60s/20s, left unset on this rig).
 
 > **⚠️ Registration follows this config, and flipping it is a BOTH-NODES change.** Since
 > 2026-08-18 `LocalDbSetup.OnReady` installs the change-capture triggers only when the node is