probe: GetProviders=0 — alarm path upstream-blocked on dev rig

Extended AlarmClientWmProbeTests to call AlarmClient.GetProviders
after RegisterConsumer. Run 2026-05-01:

  GetProviders -> rc=0 count=0 list=[]

Zero alarm providers visible to the consumer. This explains every
preceding probe run — no providers means no alarm events,
regardless of subscription expression or value writes upstream.
Even with a System Platform script flipping
TestMachine_001.TestAlarm001 every 10s during the run,
GetStatistics reported no transitions, no positions[] entries,
no field changes after t=0.85s.

Possible causes (dev-rig configuration, not code):

1. No $Alarm extension on the test bool — flipping the value
   writes a value but doesn't fire an alarm.
2. AVEVA alarm-manager service (aaAlarmMgr or equivalent) not
   running on this rig.
3. Process security context — providers registered under a
   service account aren't visible to a consumer running under
   a normal user account.

A.2 implementation is blocked on this until at least one provider
is visible. Once a provider exists, the polling-vs-callback
question is answerable in one probe run; without a provider both
paths return the same "nothing happening" answer.

Probe changes:

- Added in-process MxAccess Write attempt (TriggerWriteValue) —
  hit TargetParameterCountException so the Write signature is
  not (handle, item, value); reflection diag added but not
  resolved. Now disabled in favor of external trigger.
- Added GetProviders enumeration after RegisterConsumer.
- Removed firePrint/clearPrint markers; probe is observe-only.
- Added ArchestrA.MxAccess reference to the test project.

Also updated docs/AlarmClientDiscovery.md with the
alarm-provider-visibility section explaining what's blocked
and why.

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

docs/AlarmClientDiscovery.md

@@ -157,6 +157,57 @@ AVEVA's own message-pump thread — confirmable by extending the
 probe to fire `GetStatistics` on its own thread and check the
 result.
 
+## Alarm-provider visibility — third probe run, 2026-05-01
+
+Extended the probe to call `AlarmClient.GetProviders` after
+`RegisterConsumer`. Result on this rig:
+
+```
+GetProviders -> rc=0 count=0 list=[]
+```
+
+**Zero alarm providers visible to the consumer process.** This
+explains every preceding probe run: no providers means no alarm
+events, regardless of how many times any value (including a
+bool with an `$Alarm` extension) flips. `Subscribe(@"\Galaxy!")`
+returns 0 (success) but matches nothing because the alarm-manager
+chain that provides the matching feed doesn't expose any provider
+to this consumer.
+
+A System Platform script flipping `TestMachine_001.TestAlarm001`
+every 10s during this probe run produced no observable
+`GetStatistics` transitions, no `positions[]` / `handles[]`
+entries, no change in any field — confirms the silence is not
+about subscription-scope / message-pump but about provider
+absence.
+
+### Possible causes
+
+1. **No `$Alarm` extension on the test bool.** If
+   `TestMachine_001.TestAlarm001` is a regular UDA without a
+   `BoolAlarm` extension wired to it, flipping the value just
+   writes a new value — no alarm fires.
+2. **Alarm manager service not running.** AVEVA's `aaAlarmMgr`
+   (or the equivalent on this rig's Platform version) needs to
+   be running for providers to register.
+3. **Process security context.** A consumer running under a
+   normal user account may not see providers that registered
+   under `LocalSystem` / a Platform service identity. The
+   gateway-worker installation runs under a service account
+   that may have access where `dotnet test` doesn't.
+
+### Implications for A.2 implementation
+
+The A.2 PR's value is unmeasurable until at least one alarm
+provider is visible. The choice between polling-via-`GetStatistics`
+and the callback path can only be decided by observing what
+populates first when a real alarm fires. Without a provider,
+both paths return the same "nothing happening" answer.
+
+Until that's resolved, A.2 implementation work is genuinely
+blocked on a dev-rig configuration issue — not on architectural
+choice or code structure.
+
 ## GetStatistics polling — second probe run, 2026-05-01
 
 Extended the probe to call `GetStatistics` every ~2s alongside the