fix(opcuaclient): an acknowledge with no reply fails with its transport status (R06:O-8)

AcknowledgeAsync swallowed every non-cancellation transport failure (and returned
normally when the session was lost while the ack queued), so the host logged the
Part 9 ack as applied while upstream still showed it unacknowledged. Both now throw
(ServiceResultException with the transport status / BadNotConnected). A reply,
including per-ack refusals, still returns normally and counts as the server answering.

Refs #743

Claude-Session: https://claude.ai/code/session_01Ub9hGmYLQvn9XETzw7CMsT

docs/drivers/OpcUaClient.md

@@ -231,6 +231,12 @@ initialise (the AdminUI form drops them on the next save). Pinned by
 > 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`.
+>
+> **An ack that never got a reply fails (review 2026-10-21 O-8).** A transport failure on the `Acknowledge` call
+> (closed channel, faulted session) — or a session lost while the ack queued — now throws with its status
+> (`ServiceResultException`, e.g. `BadConnectionClosed` / `BadNotConnected`), so the host logs the ack as failed
+> instead of applied. A *reply* still returns normally, including per-ack refusals such as
+> `BadConditionBranchAlreadyAcked` (logged per ack): a refusal is the server answering.
 
 > This driver does **not** implement `IRediscoverable` — there is no
 > push-driven rediscovery signal from a remote OPC UA server in this driver.