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

deferment.md

@@ -64,13 +64,14 @@ change:
 | **#507** | **Superseded, not migrated** — the requested migration was impossible, since both of the path's inputs are structurally empty in v3. |
 | **#523** | Done, with the consequence carried forward: **AbCip and FOCAS now have no tag-change signal at all.** |
 
-**17 issues remain open** (verified against the tracker API, not derived): #519, #520 (two judgement
-calls), #524 + #525 (both split out of the #521/#522 work rather than folded in), #517, the eight MQTT
-follow-ups (#508–#515), #491, #489, #481, #468.
+**14 issues remain open** (verified against the tracker API 2026-07-31, not derived): #520 and #525
+(the two remaining judgement calls), the eight MQTT follow-ups (#508–#515), #491, #489, #481, #468.
 
-The count is unchanged at 17 but the *membership* is not — **#521 and #522 closed, #524 and #525 opened.**
-Both new ones are residuals their parent issue's decision did not cover: a second dead table
-(`DriverInstanceResilienceStatus`) and two now-consumerless `IDriver` members.
+Membership moved across three rounds: **#521 and #522 closed, #524 and #525 opened** (both residuals
+their parent issue's decision did not cover — a second dead table and two consumerless `IDriver`
+members), then **#524 closed** with the table dropped, then **#517 and #519 closed** — leaving 14.
+What is left is no longer a dead-surface cluster: #520 and #525 are keep-or-delete calls, and the
+rest are MQTT follow-ups plus four infrastructure-gated items.
 
 ---
 
@@ -1067,6 +1068,79 @@ action**, so a broken mutation produced a clean-looking verification. The cheap
 artifact rather than the exit code — `wc -l deferment.md` after an edit, `git rev-parse` after the
 commit is final rather than before.
 
+### 2026-07-31 — #517 driver health ordering + #519 status sub-codes
+
+Both closed. Each issue's *symptom* held up; each issue's *stated mechanism* was partly wrong, and in
+one case its suggested fix would have made things worse.
+
+**#519 — the sub-code collapse.** Exactly as filed: `DriverInstanceActor.QualityFromStatus` projected
+the driver's `uint` onto a 3-state enum, `OtOpcUaNodeManager.StatusFromQuality` re-expanded `Bad` to
+`0x80000000`, and no driver's sub-code ever reached a client. Resolved by **option (b)** — the raw
+`uint` now rides the whole value path — chosen by the user over "accept and document".
+
+The issue costed option (b) as "the sink interface and its three implementations". The real surface
+was **41 files / ~205 references**, because `OpcUaQuality` had producers that are not drivers and
+therefore had no `uint` to carry: `AddressSpaceApplier`'s four removal writes, `VirtualTagActor`,
+`AlarmConditionSnapshot`, and the alarm-quality path. Most had a natural code (`BadInternalError` for
+a failed script, `BadNoCommunication` for comms loss) and **two already computed one and threw it
+away** — `ScriptedAlarmHostActor` held a pair of mutually-inverse mappers converting `uint`→enum→`uint`
+around the engine, both now deleted.
+
+Two behaviour changes worth knowing, both deliberate:
+
+- `WriteAlarmQuality` fires its Part 9 event on a **status-code** change, where it used to fire on a
+  severity-bucket change. While the annotation was 3-state those were the same predicate; now a move
+  between two Bad reasons genuinely changes what a subscriber reads, so suppressing it would leave
+  clients holding a stale reason.
+- `AddressSpaceApplier`'s removal writes **kept the generic `Bad`**. A removed node could say something
+  truer (`BadNodeIdUnknown`), but #519 was about not *losing* a code the driver already had; inventing
+  a new one for the deploy path is a separate call, so that stayed behaviour-identical.
+
+**#517 — health published after teardown.** The symptom is real but the issue named the wrong path,
+and its fix was unsafe:
+
+- **`ShutdownAsync` cannot race.** `DriverInstanceActor` calls it from `PostStop` — actor thread, after
+  the mailbox drains — so the health poll is serialised against it. The one class with a lock-protected
+  concurrent `GetHealth`, `Core/Hosting/DriverHost`, **has no production call site at all** and removes
+  the driver from its registry before shutting it down anyway.
+- **`InitializeAsync` can.** It runs on a fire-and-forget `Task.Run` (`DriverInstanceActor.cs:567`), so
+  the health tick keeps firing throughout. `MTConnectDriver` writes `Healthy`, then starts its stream
+  and probe loops — either can throw into a `catch` that disposes the client and only *then* writes
+  `Faulted`. That window is the issue's claim, made concrete, and it is the only reachable one.
+- **The suggested fix — "write the transitional value before disposing" — inverts the terminal state
+  if applied as a move.** Teardown drains in-flight loops that write health as they unwind, so a
+  late loop can overwrite the shutdown value with `Healthy` and leave *that* at rest, connections
+  closed. The correct shape is a **bracket**: conservative before, terminal after. Applied to
+  MTConnect's init-failure path; the shutdown paths keep their single trailing write, and the rule +
+  the reachability table are documented on `IDriver.ShutdownAsync` so nobody "fixes" the ordering on
+  the wrong premise later.
+- **One unambiguous defect, deterministic rather than racy:** `CalculationDriver.GetHealth()` returned
+  a hard-coded `Healthy` that consulted nothing — Healthy before initialize, after shutdown, and after
+  dispose. Its existing test was literally named `Health_is_always_Connected` and asserted the defect;
+  removed, and replaced with a lifecycle test.
+
+**Falsification.** Every new guard was proved capable of failing by breaking the production code and
+watching it go red: the Commons parity guard (corrupt a constant), the node-manager verbatim write
+(restore the collapse), and the MTConnect ordering test (delete the pre-teardown write). The two
+sub-code tests each assert **two different** Bad codes, because under the old projection a
+single-code assertion could pass against a hard-coded constant.
+
+**One self-inflicted defect, caught by the suite.** The bulk `.Quality` → `.StatusCode` rename ran with
+a negative lookbehind for `condition` to protect the SDK's `condition.Quality`, which missed
+`BrowseNames.Quality` — an SDK browse-name constant. The event filter then selected a field that does
+not exist, and the wire test failed with an `NullReferenceException` on the cast rather than a readable
+assertion. Same lesson as the round-3 entries above: a mechanical rewrite needs its output audited by
+receiver, not just compiled — `git diff | grep -o '[A-Za-z_]*\.StatusCode' | sort -u` would have shown
+it in one line. It hit **twice**: `BrowseNames.Quality` (caught by the wire test) and a `.Quality`
+inside a script-source string literal in `EquipmentScriptPathsTests`' `InlineData` — which compiled
+and passed, so only reading the diff by hand found it.
+
+**Pre-existing, not chased:** the four `Driver.AbLegacy.IntegrationTests` failures need the
+slc500/micrologix/plc5 compose profiles, which are not up on `10.100.0.35` (only the AbCip
+controllogix fixture is). Reproduced on a stashed tree before dismissing them.
+
+---
+
 ---
 
 *§1–§8 generated 2026-07-27 against `master` @ `90bdaa44` by five parallel source-verification agents.