fix(opcua,drivers): carry driver status sub-codes to clients (#519) + health-write ordering (#517)

#519 — a driver's OPC UA status code now reaches a client with its sub-code intact.
DriverInstanceActor projected the driver's uint onto a 3-state Good/Uncertain/Bad enum
and OtOpcUaNodeManager re-expanded Bad to a bare 0x80000000, so BadNoCommunication,
BadTypeMismatch and BadNotSupported were indistinguishable on the wire and every
driver's status constants (incl. the 16 #497 had just corrected) were diagnostic in
logs only. Resolved by option (b): the raw uint rides AttributeValuePublished ->
AttributeValueUpdate -> IOpcUaAddressSpaceSink.WriteValue, OpcUaQuality is deleted, and
severity classification is a helper (OpcUaStatus.IsGood/IsUncertain/IsBad).

The surface was wider than the issue costed (41 files, not "the sink and 3
implementations"): OpcUaQuality had non-driver producers with no uint to carry.
Each got its natural code — BadInternalError for a failed virtual-tag script,
BadNoCommunication for driver comms loss — and ScriptedAlarmHostActor's pair of
mutually-inverse uint<->enum mappers is deleted, having round-tripped a code the
engine already held. AddressSpaceApplier's removal writes deliberately keep the
generic Bad: not losing a code the driver had is this issue; inventing one for the
deploy path is a separate call.

Behaviour change: WriteAlarmQuality fires its Part 9 event on a status-code change
rather than a severity-bucket change. While the annotation was 3-state those were the
same predicate; now a move between two Bad reasons changes what a subscriber reads.

New SDK-free named constants live on Commons.OpcUa.OpcUaStatus, and
StatusCodeParityTests is widened to cover them — that guard is reflection-driven, so
it can only see a named constant, never an inline literal.

#517 — the symptom is real but the issue named the wrong path and its fix was unsafe.
ShutdownAsync cannot race: DriverInstanceActor calls it from PostStop, after the
mailbox drains. (Core/Hosting/DriverHost, the one class with a concurrent GetHealth,
has no production call site.) InitializeAsync can: it runs on a fire-and-forget
Task.Run, and MTConnectDriver writes Healthy then starts loops that can throw into a
catch which disposes the client before writing Faulted.

Moving the write earlier, as suggested, inverts the terminal state — teardown drains
in-flight loops that write health as they unwind, so a late loop could leave Healthy at
rest with every connection closed. The fix is a bracket (conservative before, terminal
after), applied to MTConnect's init-failure path only; shutdown keeps its single
trailing write, and the rule plus the reachability table are documented on
IDriver.ShutdownAsync.

CalculationDriver.GetHealth returned a hard-coded Healthy that consulted nothing —
Healthy before initialize, after shutdown and after dispose. Now derived from _running.
Its test, named Health_is_always_Connected, asserted the defect and is replaced.

Every new guard was falsified by breaking the production code and watching it go red.
The two sub-code tests each assert two different Bad codes, since a single-code
assertion could pass against a hard-coded constant under the old projection.

Pre-existing failures, verified unchanged on a stashed tree and not chased: 4 in
Driver.AbLegacy.IntegrationTests (slc500/micrologix/plc5 fixtures not up) and 3 in
Host.IntegrationTests.

Closes #517
Closes #519

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

src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Calculation/CalculationDriver.cs

@@ -262,8 +262,22 @@ public sealed class CalculationDriver : IDriver, IDependencyConsumer, ISubscriba
         return Task.CompletedTask;
     }
 
-    /// <inheritdoc />
-    public DriverHealth GetHealth() => new(DriverState.Healthy, _lastComputeUtc, null);
+    /// <summary>
+    ///     Current health, derived from the driver's own lifecycle state.
+    ///     <para><b>Gitea #517.</b> This used to return a hard-coded <see cref="DriverState.Healthy"/> that
+    ///     consulted nothing. That made it the fleet's one driver whose <c>GetHealth()</c> reported Healthy
+    ///     <em>with its timers stopped</em> — not as a race window, but permanently and deterministically:
+    ///     before <see cref="InitializeAsync"/>, after <see cref="ShutdownAsync"/>, and after
+    ///     <see cref="Dispose"/>. Every other driver reads a <c>_health</c> field that shutdown lands on
+    ///     <see cref="DriverState.Unknown"/>.</para>
+    ///     <para>There is no transport to be Degraded about — this driver computes from the dependency mux,
+    ///     so its only meaningful states are "running" and "not running". <c>_running</c> is the flag the
+    ///     compute paths themselves gate on, which is what makes it the honest input here.</para>
+    /// </summary>
+    /// <returns>Healthy while running; otherwise Unknown, retaining the last compute time.</returns>
+    public DriverHealth GetHealth() => _running
+        ? new DriverHealth(DriverState.Healthy, _lastComputeUtc, null)
+        : new DriverHealth(DriverState.Unknown, _lastComputeUtc, null);
 
     /// <inheritdoc />
     public long GetMemoryFootprint() => 0;

src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.MTConnect/MTConnectDriver.cs

@@ -2453,6 +2453,20 @@ public sealed class MTConnectDriver : IDriver, IReadable, ISubscribable, ITagDis
         }
         catch (Exception ex)
         {
+            // Gitea #517 — land Faulted BEFORE anything is disposed, not after.
+            //
+            // A successful connect writes Healthy above, and the steps that follow it (stream start, probe
+            // loop) can still throw. Without this first write the driver would report Healthy for the whole
+            // duration of the teardown below, with its client already disposed. That window is genuinely
+            // observable: DriverInstanceActor invokes InitializeAsync on a fire-and-forget Task.Run, so its
+            // health-poll tick keeps calling GetHealth() on the actor thread throughout.
+            //
+            // The write is then REPEATED after the teardown, and both are load-bearing. Teardown drains
+            // in-flight loops, and those loops write health too — so a driver that only moved the write
+            // earlier could have a late loop overwrite Faulted with something rosier and leave THAT as the
+            // terminal state. Conservative during the window, correct at the end.
+            WriteHealth(new DriverHealth(DriverState.Faulted, lastRead, ex.Message));
+
             // A client this attempt built is unreachable from anywhere else; one the caller handed in
             // is disposed by the teardown below. Either way nothing survives a failed start.
             SafeDispose(built);