docs(register+decision): rows 69/70/78/79/80 — site-a LocalDb corruption recovered, auto-down deprecation drill-verified benign (explicit provider-class wins; re-drill on every Akka bump), replication-seeded configs start no actors (row-67 side door), OrbStack virtiofs hazard, non-null localDb health fields on unreplicated sites

docs/plans/2026-07-21-auto-down-availability-decision.md

@@ -111,3 +111,21 @@ mis-explanation in the repo ("the alone-oldest is dead and cannot down itself").
 - Monitoring already surfaces dual-active if it ever happens: both nodes report
   `IsActive` in heartbeats / both `/health/active` = 200 — the Health dashboard shows
   two Primaries.
+
+## Postscript 2026-08-15 — the deprecation warning is benign (drill-verified), but pins us for Akka bumps
+
+Every node logs at Cluster start: *"The `auto-down-unreachable-after` feature has been
+deprecated as of Akka.NET v1.5.2 … The `keep-majority` split brain resolver will be used
+instead."* Investigated and drill-verified on 1.5.62 (the same version this decision was
+made and drilled on): the warning fires purely on the **presence of the key** and the
+substitution does **NOT** happen when `downing-provider-class = "Akka.Cluster.AutoDowning"`
+is set explicitly, as `BuildHocon` does. Proof by discriminating drill (`DRILL_MODE=active`,
+2026-08-15): killing central-a — oldest AND lowest-address — left central-b to take over
+(OldestChanged → all singletons moved, victim rejoined ready 2s after restart). Under
+keep-majority, a 2-node even split keeps the lowest-address side, so central-b would have
+downed ITSELF; it demonstrably did not. The decision stands exactly as written.
+
+The real exposure is forward-looking: `AutoDowning` is deprecated and can be REMOVED by a
+future Akka.NET release. **Any Akka version bump must re-run `DRILL_MODE=active
+bash docker/failover-drill.sh` and re-read the release notes before being accepted**
+(deferred-work register row 70).