test+docs(mtconnect): wire test for the Unavailable blip + ack survival; docs for the review rulings (#626)

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

docs/AlarmTracking.md

@@ -302,11 +302,14 @@ verbose mode) read the new fields when present.
 
 An MTConnect raw tag bound to a `CONDITION` DataItem becomes a native condition when its `TagConfig`
 carries the standard `alarm` object (opt-in; without it the tag stays the String state word). Normal →
-inactive, Warning → active 500, Fault → active 800, Unavailable → inactive with `BadNoCommunication`
+inactive, Warning → active 500, Fault → active 800, Unavailable → state unchanged (an active condition stays
+active and acked — it is comms loss one hop out, the #477/#481 posture) with `BadNoCommunication`
 quality. Two optional `AlarmEventArgs` fields added for it are generic: **`OpcUaSeverity`** (an exact
 1..1000 severity that supersedes the four-bucket mapping in `NativeAlarmProjector`) and
-**`QualityStatusCode`** (projected onto the condition's `Quality`; with an `Unspecified` kind it is a
-**quality-only annotation** — `DriverHostActor` writes the condition but publishes no `/alerts` row).
+**`QualityStatusCode`** (projected onto the condition's `Quality` on a transition; with an `Unspecified`
+kind it is a **quality-only annotation** — `DriverHostActor` routes it through the same
+`AlarmQualityUpdate` → `WriteAlarmQuality` path as the connectivity annotation, which touches Quality and
+nothing else, and publishes no `/alerts` row).
 Acknowledge is server-side only (MTConnect has no ack; the driver's `AcknowledgeAsync` is a no-op).
 The driver diffs against what the server was last told, so a reconnect's replayed `/current` never
 re-raises (and so un-acknowledges) an unchanged condition. Full mapping: