probe: GetStatistics polling viable, Galaxy has no active alarms today

Extended AlarmClientWmProbeTests.ProbeAlarmClientWmMessages to also
call GetStatistics every ~2s during the pump window. Re-ran on the
dev rig 2026-05-01:

- GetStatistics is safely callable from the same thread that did
  RegisterConsumer + Subscribe. Every poll (9 calls / 20s window)
  returned rc=0, no exceptions.
- Galaxy currently has zero active alarms. total=0 active=0
  suppressed=0 newAlarms=0 across every poll. positions[] and
  handles[] arrays were empty.
- changes=1 codes=[7] was constant across all polls, matching the
  constant 1 Hz WM 0xC275 cadence — same heartbeat semantics
  exposed through both the WM path and the pull API.

Confirms the polling design is mechanically viable: GetStatistics
threading-affinity is fine and the call is cheap. The remaining
unknown is whether GetStatistics populates positions[] / handles[]
with real entries when an alarm actually fires. Proving that
requires triggering an alarm — next probe is an MxAccess write to a
$Alarm-extended boolean tag (reference pending).

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

docs/AlarmClientDiscovery.md

@@ -157,20 +157,48 @@ AVEVA's own message-pump thread — confirmable by extending the
 probe to fire `GetStatistics` on its own thread and check the
 result.
 
+## GetStatistics polling — second probe run, 2026-05-01
+
+Extended the probe to call `GetStatistics` every ~2s alongside the
+WM logger. Key findings:
+
+- **`GetStatistics` is safely callable from the same thread that
+  did `RegisterConsumer` + `Subscribe`.** Every poll returned rc=0
+  with no exceptions over 9 polls / 20s window.
+- **The deployed Galaxy currently has zero active alarms.** Every
+  poll reported `total=0 active=0 suppressed=0 newAlarms=0`. The
+  `positions[]` and `handles[]` arrays were empty.
+- **`changes=1 codes=[7]` was constant across all polls**, matching
+  the constant 1 Hz WM 0xC275 cadence. Code 7 is consistent with a
+  "heartbeat / subscription healthy" sentinel — same semantics as
+  the WM but reported through the pull-side API.
+- `percent=100` (query-complete percentage) was constant — the
+  subscription is steady-state.
+
+This confirms the polling design (option 1 in the previous section)
+is mechanically viable. The remaining open question is whether
+`GetStatistics` populates `positions[] / handles[]` with real
+entries when an alarm transition actually fires — proving that
+requires firing an alarm.
+
 ## Open follow-up probes
 
 Each can be added to `AlarmClientWmProbeTests` as a separate
 Skip-gated test:
 
-1. **Fire a real Galaxy alarm during the pump window.** Confirms
-   whether the WM 0xC275 cadence changes (becomes per-change rather
-   than periodic) and whether `GetStatistics` returns a non-empty
-   `ChangeCodes / ChangePos / hAlarm` triple.
-2. **Call `GetStatistics` on a different thread from the
-   `RegisterConsumer` thread** to test threading affinity.
-3. **Hook AVEVA's internal window** to log what WMs it actually
-   processes (would resolve option 2 above).
-4. **Decompile `aaAlarmManagedClient.dll`'s IL** for the
+1. **Fire a real Galaxy alarm during the pump window.** The cleanest
+   programmatic trigger is an MxAccess write that flips a
+   `$Alarm`-extended boolean to true (alarm in) and back to false
+   (alarm out). Pinning the exact tag reference is pending — needs
+   either a documented test-fixture tag or an interactive selection
+   in System Platform IDE. Once the trigger fires, this resolves
+   whether AVEVA's pulled change set arrives via `GetStatistics`
+   `positions[] / handles[]` (per-change polling works) or only via
+   the AVEVA-internal window (callback path needed).
+2. **Hook AVEVA's internal window** to log what WMs it actually
+   processes — only relevant if probe 1 shows `GetStatistics` does
+   NOT report per-change activity.
+3. **Decompile `aaAlarmManagedClient.dll`'s IL** for the
    `RegisterConsumer` method to find what `RegisterWindowMessage`
    string is used and whether there's a callback-registration
    surface on `WNAL_Register` that the managed client wraps. The