fix(opcuaclient): #676 live gate A1 — a sustained closed connection is a definitive loss

Live gate A1 (docker-dev, opc-plc restart / SIGINT / kill): the fast path never fired —
a real process stop delivers no session status; the keep-alives report
BadSecureChannelClosed (0x80860000) once, then BadConnectionClosed (0x80AE0000)
interleaved with BadNoCommunication for the whole outage.

Reproduced in-process with TcpStallProxy.HardClose (reset every connection, refuse new
ones; server and session alive behind it): the identical sequence, and the SDK 1.5.378
session never opens a new connection on its own (48 s with the proxy accepting again,
zero attempts) — a closed channel cannot recover in place.

The driver now treats BadSecureChannelClosed/BadConnectionClosed as definitive on the
SECOND closed-channel keep-alive failure in one outage (a good keep-alive resets the
count), raising ConnectionLost ~1 keep-alive after the drop. BadNoCommunication /
BadRequestTimeout / BadNotConnected (stall/pause) stay with the watchdog; the stall test
still sees no ConnectionLost. New wire test (hard close + reopen ⇒ raised once, SDK never
reconnects, reinit brings the identical value back Good) and unit tests (sustained raises
once; a single blip that recovers does not) — all red on the previous code. Docs updated.

docs/DriverLifecycle.md

@@ -458,11 +458,15 @@ alternatives:
   communication" — must not raise: a stalled link that resumes keeps its session, subscriptions and in-place recovery,
   and tearing it down would cost all three. Those stay with the watchdog, whose conjunction is the honest test for them.
 - **Today only `OpcUaClientDriver` implements it:** keep-alive `BadSessionIdInvalid` / `BadSessionClosed` /
-  `BadSessionNotActivated` / `BadServerHalted`, or a subscription the server REPORTED dropped (not the driver's
+  `BadSessionNotActivated` / `BadServerHalted`; a CLOSED connection (`BadSecureChannelClosed` /
+  `BadConnectionClosed`) once sustained — the second closed-channel keep-alive in one outage, which is what a real
+  process stop actually produces (live gate A1), and the SDK never reopens a closed connection by itself; or a
+  subscription the server REPORTED dropped (not the driver's
   publishing-stall heuristic, which is an inference from silence and stays with the watchdog; see
   [OpcUaClient.md](drivers/OpcUaClient.md) §"Upstream outage and recovery" for why `BadServerHalted` is on the list —
-  it was measured, the SDK never re-opens a halted channel). A gracefully restarted upstream therefore recovers in
-  about one reconnect interval instead of ~100 s; a killed one still waits for the watchdog.
+  it was measured, the SDK never re-opens a halted channel). A restarted, stopped or killed upstream therefore
+  recovers in about one keep-alive plus one reconnect interval instead of ~100 s; a stall/pause
+  (`BadRequestTimeout`/`BadNoCommunication`) still goes through the watchdog and keeps its in-place recovery.
 - ⚠️ **Known gap:** "only while `Connected`" plus "once per connection" means a raise the host receives while not yet
   Connected (e.g. the protocol proves the fresh connection dead before `InitializeSucceeded` is processed) is swallowed,
   and that connection falls back to the watchdog — the pre-#676 recovery time, in a narrow window.