docs(alarms): record native alarms verified working; add D.1 smoke

The 2026-04-30 alarm plan banners claimed worker-side native alarm
subscription was blocked on a COM-bitness finding. That's stale: the
mxaccessgw .NET client now has true MxAccess alarm-event support, and a
live StreamAlarms check (+ new Skip-gated GatewayGalaxyAlarmFeedLiveTests
through the lmxopcua consumer) confirms native alarms — operator comment,
category, severity, timestamps — flow end-to-end. Reconcile both plan docs
to reality and add docs/plans/alarms-d1-smoke-artifact.md as the D.1
alarm-source deliverable. Historian-write live smoke + full server->A&C
round-trip remain (Windows parity rig only).

docs/plans/alarms-worker-wiring-plan.md

@@ -1,5 +1,18 @@
 # Alarms Worker Wiring Plan
 
+> ✅ **UPDATE 2026-05-29 — the blocker below is RESOLVED on the gateway side; this
+> plan is largely complete.** A live `StreamAlarms` check against `10.100.0.48:5120`
+> returns the active-alarm snapshot with full native metadata **including
+> `operatorComment`**, and the lmxopcua consumer ingests it end-to-end (passing live
+> test `GatewayGalaxyAlarmFeedLiveTests`). So **A.2 / A.3 / A.4** are functionally done
+> at the gateway boundary (the worker now emits native alarm transitions and the client
+> exposes `AcknowledgeAlarm` / `QueryActiveAlarms` RPCs). **C.1** ships real code
+> (`SdkAlarmHistorianWriteBackend` → `HistorianAccess.AddStreamedValue`). **D.1**'s
+> alarm-source leg is captured in `docs/plans/alarms-d1-smoke-artifact.md`. Only two
+> things remain, both needing the Windows parity rig: C.1's live historian-write smoke
+> and a full running-server → OPC UA A&C round-trip. The per-item detail below is kept
+> as the historical record of the original blocked state.
+>
 > **Context**: The alarms-over-gateway epic shipped 19 PRs across the
 > `lmxopcua` and `mxaccessgw` repos (merged 2026-04-30). Contracts are live;
 > the sub-attribute fallback path keeps Galaxy alarms functional today. Four
@@ -16,7 +29,7 @@
 
 ---
 
-## Dev-rig finding that blocks everything (2026-04-30)
+## Dev-rig finding that blocks everything (2026-04-30) — [SUPERSEDED 2026-05-29]
 
 During PR A.2 work the following was discovered on the dev box:
 
@@ -318,16 +331,20 @@ fallback as production).
 
 ## Summary of blocks
 
-| Item | Blocked by | Estimated effort once unblocked |
-|------|-----------|--------------------------------|
-| A.2 | Architectural decision (x64 alarm-helper vs. sub-attribute fallback as production) | 2–3 days implementation; 1 day tests |
-| A.3 | A.2 delivering WorkerEvent bodies | 1–2 days |
-| A.4 | A.2 (active-alarm query needs AlarmClient session) | 1 day |
-| C.1 | aahClientManaged SDK access (available on dev box); NOT blocked by A.2 | 1–2 days |
-| D.1 | A.2 + A.3 + C.1 all passing on parity rig | 0.5 day (smoke + artifact capture) |
+> **Resolved as of 2026-05-29** — see the update banner at the top and
+> `docs/plans/alarms-d1-smoke-artifact.md`. Original status table kept for history.
 
-C.1 can proceed in parallel with A.2 / A.3 since the sidecar's `aahClientManaged`
-is x64 and does not share the worker bitness constraint.
+| Item | Status (2026-05-29) | Original block |
+|------|--------------------|----------------|
+| A.2 | ✅ **True MxAccess alarm-event support** in the gateway client (real alarm-event subscription, not the sub-attribute fallback); verified via live `StreamAlarms` with operator-comment fidelity | Architectural decision (x64 alarm-helper vs. sub-attribute fallback) |
+| A.3 | ✅ Dispatch + `AcknowledgeAlarm` RPC present on the client surface | A.2 delivering WorkerEvent bodies |
+| A.4 | ✅ `QueryActiveAlarms` RPC present on the client surface | A.2 (active-alarm query needs AlarmClient session) |
+| C.1 | ✅ Code shipped (`AddStreamedValue` path); ⏳ live historian-write smoke needs the Windows rig | aahClientManaged SDK access |
+| D.1 | ◑ Alarm-source leg captured (`alarms-d1-smoke-artifact.md`); ⏳ historian-write leg + full server→A&C round-trip need the Windows rig | A.2 + A.3 + C.1 all passing on parity rig |
+
+The gateway delivers operator-comment fidelity through **true MxAccess alarm-event
+support** in the mxaccessgw .NET client — a real alarm-event subscription, not the
+value-driven sub-attribute path. The sub-attribute fallback is now legacy.
 
 ---