docs: reconcile alarms-over-gateway banner with audited source

The 'All 19 PRs merged' banner contradicted the warning paragraph in
the same block and overstated reality against the source tree. Audit
of the lmxopcua + mxaccessgw repos on 2026-05-01 found:

- 17 of 19 PRs merged. Four merged PRs ship inert scaffolds:
  - A.2: MxAccessAlarmEventSink.Attach is a no-op.
  - A.3 / A.4: NotWiredAlarmRpcDispatcher returns OK-with-diagnostic
    for AcknowledgeAlarm and an empty stream for QueryActiveAlarms.
  - C.1: SdkAlarmHistorianWriteBackend.WriteBatchAsync returns
    RetryPlease for every event with a placeholder log.
- The architectural decision the warning paragraph asks the operator
  to make was already resolved 2026-04-30. MxAccessAlarmEventSink.cs
  in mxaccessgw records that aaAlarmManagedClient.AlarmClient is x86
  net48 (same bitness as the worker), and pins the discovered API
  surface (RegisterConsumer / Subscribe / GetStatistics /
  GetAlarmExtendedRec / AlarmAckByGUID). What remains is wiring PRs
  in the worker, not architectural choice.
- D.1 smoke artifact (docs/plans/artifacts/d1-rollout-YYYY-MM-DD.md)
  not yet captured; directory does not exist.

Banner rewritten to split functional-end-to-end vs merged-but-inert
PRs explicitly so future readers don't have to reconcile the doc
against the source tree themselves.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/plans/alarms-over-gateway.md

@@ -1,16 +1,62 @@
 # Plan — alarms over the mxaccessgw gateway
 
-> ✅ **Completed 2026-04-30 — historical record.**
-> The 14-PR sequence (A.1 / A.3, B.1 / B.2 / B.3 / B.4, C.1 / C.2,
-> E.1 / E.2 / E.3 / E.4 / E.5 / E.6 / E.7) shipped. The gateway-side
-> public RPC surface, the driver-native ack path, the sidecar alarm
-> historian writer, and the five client SDKs are all live. **A.2**
-> (worker MxAccess alarm subscription) and **A.4** (worker
-> ConditionRefresh command) require the AVEVA worker host's MxAccess
-> Toolkit C++ SDK and ship as a follow-up gated on dev-rig
-> validation. **D.1** (refresh `C:\publish` + smoke-run on the dev
-> rig) ships once A.2 is hardware-verified. The remainder of this
-> document is preserved as the design record.
+> **17 of 19 PRs merged. Public contract surface and the lmxopcua /
+> sidecar consumers are live; four merged PRs ship as scaffolds
+> pending worker-side wiring.** Status reconciled against the source
+> tree on 2026-05-01.
+>
+> **Functional end-to-end today:** B.1 / B.2 / B.3 / B.4 / B.5
+> (EventPump branch, GalaxyDriver `IAlarmSource`, DriverNodeManager
+> ack routing, `WonderwareHistorianClient : IAlarmHistorianWriter`,
+> docs sweep), C.2 (sidecar wires the alarm-write slot), D.1 script
+> (`scripts/install/Refresh-Services.ps1`), E.1 – E.7 (proto regen +
+> .NET / Python / Go / Java / Rust SDK alarm methods + lmxopcua client
+> surface). The value-driven sub-attribute fallback path keeps Galaxy
+> alarms functional today.
+>
+> **Merged-but-inert scaffolds (gated on worker AlarmClient wiring):**
+>
+> - **A.2** — `MxAccessAlarmEventSink.Attach` is a no-op; the COM-side
+>   `aaAlarmManagedClient.AlarmClient` registration / subscription has
+>   not landed yet, so the gateway's
+>   `MX_EVENT_FAMILY_ON_ALARM_TRANSITION` is reserved on the wire but
+>   never emitted.
+> - **A.3** AcknowledgeAlarm + **A.4** QueryActiveAlarms — public RPC
+>   handlers in `MxAccessGatewayService.cs` route through
+>   `NotWiredAlarmRpcDispatcher` (Ack returns OK with a `worker dispatch
+>   pending dev-rig wiring` diagnostic; Query yields an empty stream).
+> - **C.1** sidecar — `AahClientManagedAlarmEventWriter` exists and the
+>   IPC slot is wired, but the production backend
+>   `SdkAlarmHistorianWriteBackend.WriteBatchAsync` returns
+>   `RetryPlease` for every event with a placeholder log — the live
+>   `aahClientManaged` SDK call site is pinned during the D.1 dev-rig
+>   smoke. Effect: scripted-alarm transitions queue locally in
+>   `SqliteStoreAndForwardSink` and the drain worker repeatedly retries.
+>
+> **Architectural decision RESOLVED 2026-04-30** (recorded in the
+> mxaccessgw repo at `src/MxGateway.Worker/MxAccess/MxAccessAlarmEventSink.cs`
+> xmldoc): the worker hosts `aaAlarmManagedClient.AlarmClient` (x86
+> .NET Framework 4.8 — same bitness as the existing MxAccess COM
+> consumer) alongside the COM consumer, sharing the worker's STA +
+> WM_APP message pump. The discovered API surface
+> (`RegisterConsumer`, `Subscribe`, `GetStatistics`,
+> `GetAlarmExtendedRec`, `AlarmAckByGUID`) is documented in that
+> file's xmldoc. The earlier concern that AVEVA's alarm SDK was
+> x64-only proved wrong against the deployed assemblies. What remains
+> is wiring PRs in the worker — session-startup `RegisterConsumer` +
+> `Subscribe`, an STA WM_APP handler that routes
+> alarm-changed messages into `EnqueueTransition`, and the worker
+> command path that calls `AlarmAckByGUID` from a gateway
+> `AcknowledgeAlarm` RPC.
+>
+> **D.1 smoke artifact**
+> (`docs/plans/artifacts/d1-rollout-YYYY-MM-DD.md`, called for in the
+> Track D test plan below) not yet captured — gated on the worker
+> AlarmClient wiring being live on the dev rig so the smoke can
+> exercise the alarm scenarios end-to-end and pin the
+> `SdkAlarmHistorianWriteBackend` SDK entry point.
+>
+> The remainder of this document is preserved as the design record.
 
 Coordinated epic across two repos: