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-over-gateway.md

@@ -9,24 +9,41 @@
 > the new RPCs; the sub-attribute fallback path keeps Galaxy alarms
 > functional today.
 >
-> ⚠️ **Worker-side native alarm subscription blocked on a dev-rig
-> finding (2026-04-30):** the MXAccess COM Toolkit at
+> ✅ **UPDATE 2026-05-29 — native alarm feed VERIFIED working; the
+> 2026-04-30 "blocked" finding below is superseded.** A live
+> `StreamAlarms` check against the gateway at `10.100.0.48:5120`
+> returned the active-alarm snapshot (20 alarms) with full native
+> metadata — `severity`, `category`, `currentState`,
+> `lastTransitionTimestamp`, **and `operatorComment`** (the field the
+> note below called "the only v1 regression"). The lmxopcua consumer
+> (`GatewayGalaxyAlarmFeed` → `GalaxyAlarmTransition` →
+> `AlarmEventArgs` → `IAlarmSource`) ingests it with full fidelity and
+> the OPC UA severity-bucket mapping applied — proven by the passing
+> Skip-gated live test `GatewayGalaxyAlarmFeedLiveTests`. `AlarmEventArgs`
+> already carries operator-comment / original-raise-time / category, so
+> **E.7 is done too**. See `docs/plans/alarms-d1-smoke-artifact.md` for
+> the captured evidence. The gateway delivers this via **true MxAccess
+> alarm-event support** in the mxaccessgw .NET client (a real
+> alarm-event subscription — **not** the sub-attribute fallback), so A.2
+> is implemented as originally specified. Still open: the scripted-alarm
+> → AVEVA Historian write-back live smoke (C.1's `Live_*` leg) and a full
+> running-server → OPC UA A&C round-trip — both need the Windows parity rig.
+>
+> ⚠️ **[SUPERSEDED — kept for history] Worker-side native alarm
+> subscription blocked on a dev-rig finding (2026-04-30):** the MXAccess
+> COM Toolkit at
 > `C:\Program Files (x86)\ArchestrA\Framework\Bin\ArchestrA.MXAccess.dll`
-> exposes no alarm-event family — only `OnDataChange`,
-> `OnWriteComplete`, `OperationComplete`, `OnBufferedDataChange`.
+> exposed no alarm-event family — only `OnDataChange`,
+> `OnWriteComplete`, `OperationComplete`, `OnBufferedDataChange` — and
 > AVEVA's `aaAlarmManagedClient` / `ArchestrAAlarmsAndEvents.SDK`
-> assemblies are x64-only and incompatible with the worker's x86
-> bitness. **Operator decision needed before
-> `MX_EVENT_FAMILY_ON_ALARM_TRANSITION` carries any events:** either
-> accept the value-driven sub-attribute path as the production
-> architecture (operator-comment fidelity is the only v1 regression)
-> or add an x64 alarm-helper sub-process alongside the worker. See
-> `src/MxGateway.Worker/MxAccess/MxAccessAlarmEventSink.cs` in the
-> mxaccessgw repo for the architectural notes. Live
-> `aahClientManaged` alarm-event write call site
-> (`SdkAlarmHistorianWriteBackend` placeholder from PR C.1) and the
-> D.1 smoke artifact ship once those decisions resolve. The
-> remainder of this document is preserved as the design record.
+> assemblies are x64-only vs. the worker's x86 bitness. The operator
+> decision (accept the value-driven sub-attribute path, or add an x64
+> alarm-helper sub-process) has since been resolved on the gateway side
+> — `MX_EVENT_FAMILY_ON_ALARM_TRANSITION` now carries events (verified
+> above). The C.1 `SdkAlarmHistorianWriteBackend` is **no longer a
+> placeholder** — it writes through the real
+> `HistorianAccess.AddStreamedValue` path (only its live-rig write
+> smoke remains).
 
 Coordinated epic across two repos: