fix(opcuaclient): #676 review fix-ups (port-less rewrite, full reconcile, delivery lock, timers)

1. RewriteEndpointUrl keeps the advertised port when the configured URL names none
   (Uri.Port -1 would have sent the session to 4840); port-less + IPv6 tests.
2. The trailing re-read repairs any (value, status) difference that is not older than
   the last delivered value — Good->Bad/Uncertain included; a read without a source
   timestamp counts as newer; an equal source time with different content is published
   (repairs the replay guard's by-design equal-timestamp drop).
3. One driver-wide delivery lock makes decide+publish atomic across live notifications,
   the recovery read and the trailing read, so an older value can never land after a
   newer one (deterministic race test via a seam).
4. Known gap documented: a ConnectionLost raised while the host is not Connected is
   swallowed and that session falls back to the watchdog.
5. Only a SERVER-reported subscription loss raises ConnectionLost; the publishing-stall
   heuristic stays with the #527 watchdog.
6. Post-recovery timers run on Task.Delay(…, Clock, ct) with a session-work CTS
   cancelled on session release and dispose.
7. Replay summary at Information only when something was dropped (Debug otherwise);
   a re-arm reports the superseded window's drops and counts afresh.
8. DriverInstanceActor: AttachHostStatusSource doc comment restored; Reconnecting
   swallows a stray DisconnectObserved (test).
9. Stall wire test: 120 s session timeout, 3000-cycle subscription lifetime, one further
   bad keep-alive tick, 60 s headroom on the post-recovery waits (5/5 green).

docs/drivers/OpcUaClient.md

@@ -60,8 +60,9 @@ GetEndpoints returns each endpoint with the URL the **server** believes it lives
 container port publish or a proxy that address is unreachable from the client — or reachable but bypassing the proxy.
 The driver therefore rewrites the selected endpoint's **host and port** to the configured URL's whenever the schemes
 match, keeping the advertised path (the SDK's own `CoreClientUtils.SelectEndpoint` rule, which the driver's
-policy-aware endpoint selection used to bypass). A different scheme is left alone; an unparseable advertised URL falls
-back to the configured one. `OpcUaClientDriver.RewriteEndpointUrl`.
+policy-aware endpoint selection used to bypass). A configured URL with **no port** keeps the advertised port (copying
+the port-less `-1` would have sent the session to 4840). A different scheme is left alone; an unparseable advertised
+URL falls back to the configured one. `OpcUaClientDriver.RewriteEndpointUrl`.
 
 ### Session lifetime
 
@@ -96,17 +97,30 @@ The session keep-alive (`KeepAliveInterval`, default 5 s) is the liveness signal
   freezes a node. The outage Bad never moves the comparison; a re-initialise resets it.
   ⚠️ **By design, inside the window a notification whose source time EQUALS the last accepted one is dropped** — so a
   status-only change that keeps the old source timestamp (not what OPC UA servers are supposed to do) is lost during
-  the window only. When the window closes the driver logs ONE Information line — `post-recovery replay window closed —
-  dropped N late notifications across M refs after recovery` — because the per-drop line is Debug and the
+  the window only (the trailing re-read below repairs it). When the window closes — or a second recovery re-arms it —
+  the driver logs ONE line, `post-recovery replay window closed — dropped N late notifications across M refs after
+  recovery`, at **Information when N > 0** and Debug otherwise, because the per-drop line is Debug and the
   `stale_notification_dropped` counter is OTel-only, which made the guard unobservable on the docker-dev rig (#676).
+  A re-arm starts the count afresh.
 - **Trailing re-read after an in-place recovery (#676).** Found by the TCP-stall wire test: a change the server
   published just after the stall ended rode a Publish response that had been in flight across the stall; the SDK
   timed that request out (`BadTimeout`), discarded the response and never republished the message (the following
   keep-alives moved the sequence number past it), so the node stayed **Good on the pre-change value indefinitely**.
   `Timeout + KeepAliveInterval` after the recovery — when every request in flight across the stall has completed or
-  timed out — every subscribed ref is read once more, and any Good value **newer** than the last one accepted for that
-  ref is published (through the replay guard's mark while the window is open, so it can never regress a node). An
-  Information line names how many refs it had to repair.
+  timed out — every subscribed ref is read once more and published when its **(value, status) differs** from the last
+  value delivered for that ref **and is not older** than it. Any status counts: a Good→Bad/Uncertain change lost in the
+  pipeline is as stale as a lost value. "Older" compares source timestamps only when both carry one; a read with no
+  source timestamp (a server that does not send them) is the server's current state and counts as newer. An **equal**
+  source timestamp with different content IS published — it is the server's current state, not a replay, and it repairs
+  the equal-timestamp status-only change the replay guard drops by design. An identical (value, status) is never
+  republished. An Information line names how many refs it had to repair. The trailing read and the replay-guard disarm
+  timer run on the driver clock and are cancelled when the session is released (re-initialise / shutdown / dispose).
+- **No older value is ever delivered after a newer one.** The three paths that publish upstream data — live
+  notifications, the recovery read and the trailing read — make their "may I publish this?" decision and the publish
+  inside one driver-wide critical section. A single lock rather than one per ref: a session's notifications arrive on
+  its publish thread one message at a time, so the only contention is a recovery/trailing read overlapping a
+  notification, and an uncontended lock costs tens of nanoseconds per notification. Subscribers run inside it — the
+  host's handler only `Tell`s an actor — so a subscriber must never block on, or call back into, the driver.
 - **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 the #527 comms-loss watchdog's trip condition; `DriverInstanceActor`
   runs `ShutdownAsync` + `InitializeAsync` (retried every 10 s while the server is down) and re-subscribes data +
@@ -117,7 +131,7 @@ The session keep-alive (`KeepAliveInterval`, default 5 s) is the liveness signal
   raises `ConnectionLost` — **once per session**, re-armed by a re-initialise — when the loss is certain, so the host
   re-initialises at once instead of after the watchdog's 90 s. Definitive means: a keep-alive status of
   `BadSessionIdInvalid` / `BadSessionClosed` / `BadSessionNotActivated` (the server forgot, closed or never activated
-  the session) or `BadServerHalted`, or a tracked subscription declared lost (below). `BadServerHalted` is on the list
+  the session) or `BadServerHalted`, or a subscription the **server** reported gone (below). `BadServerHalted` is on the list
   because it was **measured**: on the restart wire test a gracefully stopped server reports `BadServerHalted` (and the
   keep-alives alternate it with `BadNoCommunication`), and the SDK never re-opens a channel the server halted — 15 s
   after the server was back, the same session still failed every request with `BadServerHalted`; `BadSessionIdInvalid`
@@ -125,7 +139,11 @@ The session keep-alive (`KeepAliveInterval`, default 5 s) is the liveness signal
   `BadRequestTimeout`/`BadTimeout` (what a stalled link produces) — is **ambiguous** (the link may resume and keep its
   session, see the stall test) and stays with the watchdog. Consequence: a gracefully restarted upstream recovers in
   roughly one reconnect interval (≈10 s) instead of ~100 s; an upstream that vanishes without a halt (killed, cable
-  pulled) still waits for the watchdog.
+  pulled) still waits for the watchdog. ⚠️ **Known gap:** the host acts on the signal only while the driver is
+  `Connected`, and the driver raises it once per session — so a definitive loss raised while the host is not
+  Connected (e.g. `BadServerHalted` on the fresh session before the host has processed the successful initialise) is
+  swallowed and that session falls back to the watchdog. Re-raising on later keep-alives would close it but was left out
+  to keep the once-per-session contract simple; the cost is the pre-#676 recovery time, in a narrow window.
 - **The subscription dies but the session lives** (an outage longer than the subscription lifetime —
   `LifetimeCount` x publishing interval, often well under the session timeout — or a server that drops it) ⇒ keep-alives
   stay Good, so they cannot be the signal. A `PublishError` of `BadNoSubscription` (while subscriptions are tracked) or
@@ -133,8 +151,10 @@ The session keep-alive (`KeepAliveInterval`, default 5 s) is the liveness signal
   persists for one more subscription keep-alive window + 5 s across good keep-alives, declares it lost: `Degraded`
   (`"subscription lost: …"`), the outage published once, and — sticky until the session is released — **nothing**
   advances `LastSuccessfulRead` any more (not good keep-alives, not a sibling subscription's notifications), so the
-  watchdog's re-initialise recreates it. Both detectors are wire-tested independently. A dead subscription never comes
-  back on its session, so this also raises `ConnectionLost` (#676) and the re-initialise happens at once.
+  watchdog's re-initialise recreates it. Both detectors are wire-tested independently. A subscription the **server**
+  reported gone (`BadNoSubscription` / `BadSubscriptionIdInvalid`) never comes back on its session, so that also raises
+  `ConnectionLost` (#676) and the re-initialise happens at once; the `PublishingStopped` **heuristic** is an inference
+  from silence and keeps going through the watchdog.
 - An in-place recovery is bound to the session whose keep-alive recovered: one overtaken by a re-initialise neither
   publishes, nor degrades, nor re-arms the outage latch of the new session.