feat(opcuaclient): #676 follow-ups — endpoint rewrite, stall wire test, fast definitive-loss recovery

- Endpoint rewrite: the driver now connects to the configured host AND port (scheme
  match, advertised path kept) instead of the server-advertised URL — fixes NAT/port-map
  upstreams and lets an in-test proxy carry the session (SDK SelectEndpoint rule).
- TcpStallProxy + OpcUaClientDriverStallWireTests: the in-place blip (#670) is now
  wire-tested on loopback — one Bad, frozen read stamp, same session, identical value
  republished Good, a post-recovery change arrives, no source-time regression after
  the SDK's late backlog flush.
- Defect found by that test, fixed: a change published right after a stall rode a
  Publish response the SDK timed out and never republished, leaving the node Good on
  the pre-change value indefinitely. New trailing reconcile read (Timeout +
  KeepAliveInterval after recovery) publishes any Good value newer than the last
  accepted one, through the replay guard's mark.
- IDriverConnectionLossSource (Core.Abstractions): opt-in definitive-loss signal.
  DriverInstanceActor attaches in PreStart / detaches in PostStop and turns a raise
  into a disconnect only while Connected. OpcUaClient raises once per session on
  keep-alive BadSessionIdInvalid/BadSessionClosed/BadSessionNotActivated/
  BadServerHalted (measured: the SDK never re-opens a halted channel) or a dropped
  subscription; ambiguous codes stay with the #527 watchdog.
- Replay guard: one Information summary per recovery when the window closes
  ("dropped N late notifications across M refs"), with a timer so quiet
  subscriptions log it too.
- ReconnectPeriod deleted (options, AdminUI form, docs, tests); stored configs that
  carry reconnectPeriod still parse in the factory, probe and browser.
- Docs: OpcUaClient.md, DriverLifecycle.md, driver-specs.md, CLAUDE.md.

src/Core/ZB.MOM.WW.OtOpcUa.Core.Abstractions/IDriverConnectionLossSource.cs

@@ -0,0 +1,31 @@
+namespace ZB.MOM.WW.OtOpcUa.Core.Abstractions;
+
+/// <summary>
+///     Optional driver capability (Gitea #676) — a driver that can tell, from its protocol, that its connection is
+///     DEFINITIVELY gone (it can never recover in place, only a re-initialise brings it back) raises
+///     <see cref="ConnectionLost"/> so the host re-initialises it at once instead of waiting out the #527 comms-loss
+///     watchdog (~90 s of frozen <see cref="DriverHealth.LastSuccessfulRead"/>).
+/// </summary>
+/// <remarks>
+///     <para>
+///         <b>Definitive only.</b> An AMBIGUOUS failure — a timeout, a stalled socket, "no communication" — must NOT
+///         raise: the connection may yet resume in place (a <c>docker pause</c>, a congested link), and tearing it
+///         down would cost the session, its subscriptions and the in-place recovery. Ambiguous failures keep going
+///         through the watchdog, whose conjunction (non-Healthy AND a frozen read stamp) is the honest test for them.
+///     </para>
+///     <para>
+///         The host (<c>DriverInstanceActor</c>) acts on a raise only while the driver is Connected — in any other
+///         state a re-initialise is already pending or running — and it subscribes for its own lifetime, not per
+///         connect, because the <see cref="IDriver"/> instance can outlive the actor. A driver should raise at most
+///         once per connection and re-arm when it is re-initialised.
+///     </para>
+/// </remarks>
+public interface IDriverConnectionLossSource
+{
+    /// <summary>Raised (on the driver's own thread) when the driver's connection is definitively lost.</summary>
+    event EventHandler<DriverConnectionLossEventArgs>? ConnectionLost;
+}
+
+/// <summary>Event payload for <see cref="IDriverConnectionLossSource.ConnectionLost"/>.</summary>
+/// <param name="Reason">Driver-supplied reason for the diagnostic log (e.g. the protocol status that proved the loss).</param>
+public sealed record DriverConnectionLossEventArgs(string Reason);