fix(runtime): comms loss marks raw + UNS value nodes BadNoCommunication, value retained (archreview 03/S15)

archreview/plans/R3-02-stale-good-family-plan.md

@@ -678,3 +678,15 @@ test could only pass once the production change landed.
 - Metered `OpcUaSinkWrite kind:"status"` so a status annotation is separable from a value write on the
   same counter; the recording fake asserts **zero** value writes, since a handler falling through to the
   value path would null every node.
+
+### T8 — `DriverHostActor.FanCommsLossToValueNodes`
+
+- RED: `--filter "…DriverHostActorCommsLossValueNodesTests"` ⇒ **2 failed**, both
+  `Timeout 00:00:15 while waiting for a message of type …AttributeStatusBatchUpdate` (the disconnect
+  produced no value-node write at all — the finding, reproduced).
+- GREEN: 10 passed across the new suite + `DriverHostActorCommsLossTests` (mux half) +
+  `DriverHostActorBatchFanOutTests`, all unchanged.
+- **Deviation (sequencing, not design):** the plan's snippet calls `TrackCommsLatchSet(...)` from inside
+  this method, but that helper is T9's — calling it here would not compile. The call is added in T9,
+  where the latch and its audit timer land together. R3-03 boundary respected: this is a new method plus
+  one branch in `OnDriverConnectivityChanged`; `HandleRestartDriver` and the watchdog are untouched.

archreview/plans/R3-02-stale-good-family-plan.md.tasks.json

@@ -55,7 +55,7 @@
     {
       "id": "T8",
       "subject": "DriverHostActor.FanCommsLossToValueNodes: one BadNoCommunication status batch over raw + UNS nodes on ConnectivityChanged(false); nothing on reconnect (new method — R3-03 boundary)",
-      "status": "pending",
+      "status": "done",
       "blockedBy": [
         "T7"
       ]