docs(archreview): conclude docker-dev live pass — R2-10 pipeline live, R2-03 rig-blocked

R2-10: driver failures propagate through the full Polly pipeline (CircuitBreaker->
Retry->Timeout->CapabilityInvoker.cs:84) live — the #10 dispatch-gap fix + tracker
source confirmed in prod; breaker-OPEN not forced (backoff-throttled, per FOLLOWUP-10).
R2-03: rig has no driver data (all nodes Bad_WaitingForInitialData), so VT Good->Bad
can't be staged; unit-verified. 5 gates live-confirmed total; remaining items need
external infra (integration fixtures, VPN gateway, live LDAP, S7 blackhole).

archreview/plans/STATUS.md

@@ -230,7 +230,13 @@ shared docker-dev rig / VPN infra isn't contended. To run one-at-a-time:
 **R2-11 Phase C** — flip the runtime driver parsers to strict (typo'd enum ⇒ `BadNodeIdUnknown` instead of a
 wrong-width `Good`). Land only after fleets have run `Deployment:TagConfigValidationMode=Error` clean.
 
-## docker-dev live-`/run` pass (2026-07-13) — 4 gates LIVE-confirmed on the built-from-source `6aeb53a9` rig
+## docker-dev live-`/run` pass (2026-07-13) — CONCLUDED; 5 gates LIVE-confirmed on the built-from-source `6aeb53a9` rig
+
+**Bottom line:** R2-02, R2-11, R2-07 (both surgical phases), R2-04 (achievable failover), and R2-10 (resilience pipeline in
+dispatch) verified live on the docker-dev central cluster. R2-05 partial-by-design; R2-03 unit-verified (rig has no driver
+data). Everything still open needs infra this box lacks: the `*.IntegrationTests` sweep needs the `10.100.0.35` driver
+fixtures + ephemeral LDAP up; R2-06 needs VPN to a 0.2.0 gateway; R2-08 a live GLAuth outage cycle; R2-01 the S7 blackhole
+fixture. Those are the only Round-2 items not yet exercised.
 
 Brought up the 2-node central cluster (`central-1`+`central-2`, SQL, traefik) from source at merged master `6aeb53a9`
 (single-tenant rig; drove the `:9200` AdminUI via browser + Client.CLI on `:4840`/`:4841`).
@@ -252,11 +258,20 @@ Brought up the 2-node central cluster (`central-1`+`central-2`, SQL, traefik) fr
   strategy decision), **not** an R2 regression; R2-04's `PrimaryGatePolicy` write-gate change is orthogonal + unit-verified.
 - **R2-05 (T15) ✅ (partial, as expected)** — every config/read page renders under the all-roles `multi-role-test` session
   (named-policy gating didn't over-gate a legitimate admin); deny is unobservable under docker-dev `DisableLogin=true`, as documented.
-- **R2-10 (T10) / R2-03 (T12) — unit-verified; live-trigger constrained, not forced.** R2-10's breaker needs a wrapped
-  subscribe/discover/write exception (Modbus's cheap paths don't throw wrapped — the known trigger is an idempotent
-  write-to-dead-endpoint or S7). R2-03's live observable is a Client.CLI `read` StatusCode, but the CLI `read` throws a
-  `FetchValueAsync` stack trace even on valid nodes on this rig, so quality wasn't cleanly observable via CLI. Both are
-  solidly covered by unit suites (Core resilience 128, publisher/guard 6; Runtime 372, RoslynVTEvaluator 20).
+- **R2-10 (T10) ✅ pipeline LIVE (breaker-OPEN state not forced).** The `/hosts` page shows the driver-health flow live
+  (MAIN-galaxy-eq HEALTHY; MAIN-modbus-eq FAULTED "Connection refused"; MAIN-opcua-eq FAULTED "failed to connect to any
+  endpoints"). The failing drivers' subscribe/discover exceptions propagate through the **full Polly resilience pipeline** —
+  central-1 stack traces show `Polly.CircuitBreaker` → `Polly.Retry` → `Polly.Timeout` → `CapabilityInvoker.ExecuteAsync
+  (CapabilityInvoker.cs:84)`, i.e. **the #10 dispatch-gap fix + R2-10's tracker data-source are live in prod.** The explicit
+  `breaker OPENED` log line + the active resilience chip were NOT triggered: R2-09's ConnectionBackoff throttles retries, so
+  consecutive failures don't accumulate fast enough to open the Polly breaker within its window (the documented FOLLOWUP-10
+  difficulty — the reliable trigger is a rapid idempotent write-to-dead-endpoint). Reader/store/publisher/bridge are
+  unit-verified (Core resilience 128, publisher+guard 6, store 8).
+- **R2-03 (T12) — unit-verified; live-blocked on this data-less rig.** Every materialised node reads
+  `0x80320000 Bad_WaitingForInitialData` because no live driver data flows (Modbus `10.100.0.35:5020` unreachable in-rig;
+  VTs depend on driver data), so a VT can't be staged Good→Bad; and the Client.CLI `read` surfaces any Bad StatusCode as a
+  `FetchValueAsync` exception rather than printing it. Good→Bad-with-last-value transition is covered by unit suites
+  (Runtime 372, RoslynVTEvaluator 20). Would be live-observable with a reachable driver fixture feeding the VT.
 
 **Rig note:** the pass mutated the persisted ConfigDb (added a `drv-modbus-line3-01` Modbus driver on MAIN; removed
 `capper-03`'s `production-count` virtual tag for the PureRemove test). Reset with