fix(alarms): #647 re-review — re-statement needs the same message; CNC refusal is not comms loss; worst-of health

R1: NativeAlarmProjector treats Raise-on-Active as a re-statement only when the message matches what
the condition shows; a different alarm appearing during a respawn un-acks and writes its alerts row.
FOCAS condition messages are a deterministic function of the matched set (tested across fresh driver
instances and reordered lists); Runtime E2E now covers both the same alarm and a new one during a
respawn. Residual (source message determinism) documented in AlarmTracking.md.

R2: a non-OK cnc_rdalmmsg2 return is thrown as FocasWireException{Rc} and classified as a CNC
refusal: conditions get a quality-only BadNotSupported once, one Warning, polling continues, and
driver health is untouched (no 90 s watchdog reconnect loop on a production control). Only transport
faults degrade (falsification control in the test).

R3: alarm-path health is tracked apart from the value path and combined in GetHealth: worst state,
later LastSuccessfulRead. A good value read can no longer mask a failing alarm read (no per-poll
/hosts flip) and a good alarm read cannot mask a value Degraded.

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

docs/AlarmTracking.md

@@ -57,9 +57,15 @@ same condition is wired as an **event notifier of every referencing equipment fo
 - **Routing is an exact `ConditionId == RawPath` match** (`DriverHostActor.ForwardNativeAlarm`). A driver that
   decorates the id has every transition dropped as "no alarm condition" — AbCip did (`"{ref}#active"`, fixed
   under #641), and so did FOCAS (`"{host}#{Type}:{Number}"`, fixed under #647 — one condition per `ALARM:` tag, see
-  `drivers/FOCAS.md`). A `Raise` on a condition already projected Active is a **re-statement** (#647 review): the
-  ack is kept and no second "Activated" row is published — a respawned driver re-reading a still-active alarm sends
-  exactly that. Only `Retrigger` (or inactive → active) un-acks. A native source must also set `Kind`: an
+  `drivers/FOCAS.md`). A `Raise` on a condition already projected Active **with the same message** is a
+  **re-statement** (#647 review): the ack is kept and no second "Activated" row is published — a respawned driver
+  re-reading a still-active alarm sends exactly that. A Raise with a DIFFERENT message is a new statement and un-acks:
+  a respawned driver cannot tell "the same alarm" from "a different one that appeared while it was down", so the
+  host compares what the condition shows. Only `Retrigger` (or inactive → active, or a changed-message Raise) un-acks.
+  ⚠️ **Residual:** the comparison is only as good as the source's message determinism. FOCAS and MTConnect messages
+  are deterministic for an unchanged statement; a source whose message carries volatile text (a timestamp, a
+  counter) would un-ack on every respawn — conservative, never hiding an alarm — and a source whose message omits
+  what changed (a new alarm under identical text) would keep a stale ack across a respawn. A native source must also set `Kind`: an
   `Unspecified` kind projects no state change.
 
 ### Native condition state survives a full rebuild (Gitea #641)