fix(opcuaclient): upstream session loss goes Bad and recovers (#670)

A bad keep-alive now degrades health (LastSuccessfulRead preserved) and,
once per outage, publishes BadNoCommunication (value retained) for every
subscribed ref plus a quality-only annotation on subscribed alarm
conditions. Good keep-alives and data/event notifications advance
LastSuccessfulRead, so an idle-but-alive subscription never looks dead
to the #527 watchdog. A keep-alive that recovers on the same session
re-reads the Bad refs and republishes them Good; a session that does not
come back is recovered by the watchdog's ShutdownAsync + InitializeAsync
+ re-subscribe.

Deletes the SessionReconnectHandler wiring (it retried forever in SDK
1.5.378, cloned subscriptions the driver never re-tracked and kept health
Healthy), OnReconnectComplete, TryRearmReconnect and the reconnect_*
counters (new keepalive_recovered). Teardown of a lost session skips
wire deletes and bounds CloseSession. SDK warnings reach the driver log.
Wire test reworked: restart => Bad, then watchdog-style reinit => Good.

docs/drivers/OpcUaClient.md

@@ -45,22 +45,46 @@ out-of-process isolation.
 ```
 
 `EndpointUrls` (a list) takes precedence over the single-URL `EndpointUrl` and
-provides ordered **failover** — the driver tries each candidate in turn at init
-and on session drop, and the first to connect wins (e.g. a hot-standby pair on
+provides ordered **failover** — the driver tries each candidate in turn at every
+`InitializeAsync` (including the comms-loss watchdog's re-initialise), and the first to connect wins (e.g. a hot-standby pair on
 4840 / 4841). See
 `src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.OpcUaClient.Contracts/OpcUaClientDriverOptions.cs`
 for every field (security policy/mode, auth type, session timeout, keep-alive,
-reconnect period, browse root, node/depth caps).
+browse root, node/depth caps). `ReconnectPeriod` is still parsed but no longer used (#670).
 
 ### Session lifetime
 
-A single `Session` per driver instance; subscriptions multiplex onto it. The
-SDK reconnect handler takes the session down and brings it back on remote-server
-restart, re-sending subscriptions on reconnect so monitored-item handles don't
-dangle. Stored NodeIds embed the server-stable namespace **URI** (not the
+A single `Session` per driver instance; subscriptions multiplex onto it. Stored NodeIds embed the server-stable namespace **URI** (not the
 session-relative `ns=N` index) so a remote namespace-table reorder across a
 restart doesn't silently re-point references at the wrong namespace.
 
+### Upstream outage and recovery (Gitea #670)
+
+The session keep-alive (`KeepAliveInterval`, default 5 s) is the liveness signal:
+
+- **Good keep-alive / any data or event notification** advances `DriverHealth.LastSuccessfulRead` — a
+  subscription-only driver never calls `ReadAsync`, so without this its read stamp froze at connect time.
+- **Bad keep-alive** ⇒ health `Degraded` (`LastError = "keep-alive: <status>"`, read stamp preserved), host status
+  `Stopped`, and — **once per outage**, not per keep-alive — every subscribed ref is published `BadNoCommunication`
+  with its last value retained, plus a quality-only `BadNoCommunication` annotation (#626 pattern, no alarm-state
+  change, no `/alerts` row) on every subscribed alarm condition.
+- **The session survives** (a network blip; the keep-alive turns Good again) ⇒ recovered in place: health `Healthy`,
+  the refs still Bad are re-read once and published Good (a server whose subscription survived does not resend an
+  unchanged value, and a `(value, status)` dedup downstream lets the identical value through), alarm quality goes
+  back Good and a `ConditionRefresh` re-reports anything missed. A notification that lands first wins over the read.
+- **The session does not come back** (an upstream restart: the server forgot the session) ⇒ the driver stays
+  `Degraded` with its read stamp frozen, which is exactly the #527 comms-loss watchdog's trip condition. After 90 s
+  `DriverInstanceActor` runs `ShutdownAsync` + `InitializeAsync` (retried every 10 s while the server is down) and
+  re-subscribes data + alarms; the new subscription's initial values come back Good. Alarm last-told state survives
+  the re-initialise (#619), so the post-subscribe `ConditionRefresh` raises no un-ack flicker; the host's reconnect
+  annotation restores condition quality.
+
+There is **no in-driver reconnect** any more. The SDK's `SessionReconnectHandler` (removed) retried forever in SDK
+1.5.378 (its "exhausted" path was unreachable), recreated sessions by cloning subscriptions the driver never
+re-tracked, and kept health `Healthy` throughout — so on docker-dev a stopped opc-plc left nodes Good on their last
+value indefinitely and they never recovered. A teardown against a lost session skips the wire deletes and bounds
+`CloseSession` to 5 s. SDK warnings (keep-alive / publish / channel errors) now reach the driver's own logger.
+
 ### Namespace assignment (retired, Gitea #648)
 
 Earlier versions required a per-instance `TargetNamespaceKind` (`Equipment` +
@@ -107,11 +131,11 @@ initialise (the AdminUI form drops them on the next save). Pinned by
 > from whatever the host retained: an inactive+acked one goes out as `Clear` + `Acknowledge` (#657; it used to be an
 > `Unspecified` the host wrote as "Activated", and a retained-Active host condition stayed Active). So the host writes no
 > duplicate row when its condition already shows that state (see `docs/AlarmTracking.md`). Condition **branch** events (non-null `BranchId`) are ignored.
-> **`ConditionRefresh`** is called after the event item is created, after every in-place reconnect, and on a
+> **`ConditionRefresh`** is called after the event item is created, after a keep-alive outage the session survived, and on a
 > `RefreshRequired` event, so a condition already active upstream is reported at subscribe; `RefreshStart`/`RefreshEnd`
 > markers are dropped. A server without it (`BadNotSupported`/`BadMethodInvalid`/…) is logged once and tolerated.
 > Last-told state survives a re-initialise (the host re-subscribes the same set over nodes it did not rebuild) and is
-> forgotten when the subscribed set changes (the host rebuilt, recreating the nodes inactive). Index keys are server-stable (`nsu=`), so a namespace reorder across a reconnect keeps
+> forgotten when the subscribed set changes (the host rebuilt, recreating the nodes inactive). Index keys are server-stable (`nsu=`), so a namespace reorder across a re-initialise keeps
 > matching. docker-dev seeds an opc-plc driver (`MAIN-opcua`); the alarm tag is
 > created only when `@OpcPlcAlarmSourceNodeId` is set in `docker-dev/seed/seed-clusters.sql`.
 
@@ -192,8 +216,9 @@ every `InitializeAsync`, including comms-loss reconnects). The discovery channel
 Session/publish events are published on the shared OTel meter as the counter
 `otopcua.driver.opcuaclient.events`, tagged `driver_instance` (the driver instance id) and `event` =
 `publish_response`, `notification` (items), `data_change`, `bad_status_value`, `publish_error`,
-`keepalive_miss`, `reconnect_attempt`, `reconnect_success`, `reconnect_exhausted`. A climbing `keepalive_miss` /
-`reconnect_attempt` rate is the signature of a flapping upstream. They are not part of `DriverHealth` or the
+`keepalive_miss`, `keepalive_recovered` (a bad keep-alive followed by a good one on the same session). A climbing
+`keepalive_miss` / `keepalive_recovered` rate is the signature of a flapping upstream (`reconnect_*` were removed with
+the reconnect handler, #670). They are not part of `DriverHealth` or the
 `/hosts` panel.
 
 ## Testing