docs(plans): bookkeeping sync — reconcile stale trackers with merged code

A verified audit of all ~90 plan documents (2026-08-01) found ~30 .tasks.json
trackers and several plan headers still reporting 'pending'/'draft' for work
fully merged to main. Sync them so future audits don't re-litigate closed work:

- Flip ~380 stale task statuses to completed across March/May/June/July
  trackers (audit-log series, milestones M5-M10, playwright waves, stillpending,
  LocalDb, ClusterClient->gRPC DoD rows, and more), each verified against
  code/git evidence before flipping.
- Annotate obsolete-not-done rows: ClusterClient CLI transport (never built,
  HTTP shipped), TreeView Areas/Instances pages (replaced by Topology),
  template-tree drag-drop (dropped for M9 menu reorder), otopcua item C
  (premise superseded by #17).
- Flip stale headers: aggregated-live-alarm + kpi-rollups 'Draft not executed'
  -> Delivered 2026-07-10; otopcua cutover-scope SCOPING -> DECIDED;
  scadabridge-rename -> Implemented; LocalDb phase1/2 status strings ->
  merged 28ca04d7.
- Fix doc drift: T9/T10 'deferred' -> shipped as SMS (Teams dropped); waitfor
  sandbox follow-up shipped; followups #52/#53/#54/#162/#207 resolved; purge
  TODO closed by PendingDeploymentPurgeActor; live-gate pre-existing failures
  #28/#29/#31 fixed; auto-down boot-alone residual superseded by self-first
  seeds; supersession banners on keep-oldest SBR + ClusterClient-era designs;
  requirements-traceability 'Pending' clarified as frozen plan-generation
  status.

Deliberately left pending (genuinely open, tracked in the pending-work list):
opcua-tag-browser task 19 (live smoke), ipsen tasks 7-8 (vd03 verification),
selfform task 7 (vd03 overlay, user-held), live-gate observation 1
(external-system delete orphan bug), otopcua item A + maxDepth calibration.

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

@@ -97,12 +97,17 @@ mis-explanation in the repo ("the alone-oldest is dead and cannot down itself").
 
 ## Residual operational notes
 
-- **Seed-node bootstrap constraint still applies to boot-alone**: only the first seed
-  may self-form a cluster. Auto-down removes the active-crash outage (the survivor never
-  restarts), but a node that must BOOT alone while its peer is dead (cold start of only
-  the non-first-seed VM, or the survivor crashing while the peer is still down) still
-  waits in `InitJoin` for its peer. Operator recovery unchanged (restart first seed, or
-  self-first seed override).
+- ~~**Seed-node bootstrap constraint still applies to boot-alone**~~ — **SUPERSEDED
+  (2026-07-22), no longer a residual.** As written: only the first seed may self-form a
+  cluster, so a node that must BOOT alone while its peer is dead (cold start of only the
+  non-first-seed VM, or the survivor crashing while the peer is still down) waits in
+  `InitJoin` for its peer. This was **closed** by the self-first seed-node ordering change
+  (`docs/plans/2026-07-22-selfform-fallback-and-manual-failover.md`): every node now lists
+  ITSELF first in `seed-nodes`, so any node can cold-start alone and become operational
+  unattended, and `StartupValidator` fails the boot if the ordering is broken — regression
+  coverage in `SelfFirstSeedBootstrapTests`. The residual cost of self-first-on-both (a
+  *truly simultaneous* cold start racing `FirstSeedNodeProcess` on both nodes) is in turn
+  covered by the opt-in `ScadaBridge:Cluster:BootstrapGuard` (Gitea #33, default OFF).
 - 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.