docs: reconcile stale cluster/security/notification docs; close register row 117, add rows 128-135 (review 2026-10-21 wave 2)

docs/operations/failover-procedures.md

@@ -8,16 +8,16 @@
 
 1. Active central node becomes unreachable (process crash, network failure, hardware failure).
 2. Akka.NET failure detection triggers after ~10 seconds (2s heartbeat, 10s threshold).
-3. Split-brain resolver (keep-oldest) evaluates cluster state for 15 seconds (stable-after).
+3. `auto-down`: the leader among the reachable members downs the unreachable node after 15 seconds of sustained unreachability.
 4. Standby node is promoted to active. Total time: ~25 seconds.
 5. Cluster singletons migrate to the new active node.
 6. Load balancer detects the failed node via `/health/ready` and routes traffic to the surviving node.
-7. Active user sessions continue (JWT tokens are validated by the new node using the shared signing key).
+7. Active user sessions continue (the cookie's data-protected ticket is validated by the new node via the shared Data Protection key ring; CLI bearer tokens via the shared signing key).
 8. SignalR connections are dropped and Blazor clients automatically reconnect.
 
 **What is preserved:**
 - All configuration and deployment state (stored in SQL Server)
-- Active JWT sessions (shared signing key)
+- Active sessions (shared Data Protection keys for cookies, shared signing key for CLI bearer tokens)
 - Deployment status records (SQL Server with optimistic concurrency)
 
 **What is temporarily disrupted:**
@@ -82,9 +82,9 @@
 **Symptoms:** Both nodes believe they are the active node. Logs show "Cluster partition detected".
 
 **How the system handles it:**
-- Keep-oldest resolver: The older node (first to join cluster) survives; the younger is downed.
-- `down-if-alone = on`: If a node is alone (no peers), it downs itself.
-- Stable-after (15s): The resolver waits 15 seconds for the partition to stabilize before acting.
+- `auto-down` (decision 2026-07-21): each side downs the unreachable peer after 15 s and continues as a one-node cluster, so a real partition leaves BOTH nodes active until an operator restarts one side (accepted trade for ~25 s failover on either-node crash).
+- `keep-oldest` (opt-in): the older node survives and the younger is downed; but a crash of the oldest is a total outage.
+- Stable-after (15s): the window of sustained unreachability before the downing decision.
 
 **Manual intervention (if auto-resolution fails):**
 1. Stop both nodes.
@@ -96,7 +96,7 @@
 **Symptoms:** Central UI returns errors. `/health/ready` returns 503. Logs show database connection failures.
 
 **Impact:**
-- Active sessions with valid JWTs can still access cached UI state.
+- Active sessions (valid cookie or bearer token) can still access cached UI state.
 - New logins fail (LDAP auth still works but role mapping requires DB).
 - Template changes and deployments fail.
 - Sites continue operating independently.