Record the managed GUID alarm-ack live result

The 2026-10-18 live test on the dev rig showed the opt-in managed ack path
cannot work as built: AlarmClient.RegisterConsumer returns -65 alongside the
worker's wnwrap reader (the worker then silently falls back to wnwrap), the
managed client does not recognise the wnwrap GUID even standalone, and the
gateway's GUID arm sends empty identity fields. Replace the docs' claim that
the path works with the measured results and tell operators to leave
MXGATEWAY_USE_MANAGED_ALARM_ACK unset.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/GatewayConfiguration.md

@@ -446,11 +446,12 @@ behavior.
 The alarm monitor is independent of client sessions: `AcknowledgeAlarm` and
 `StreamAlarms` are session-less RPCs served by the monitor.
 
-GUID-keyed acknowledges can opt into AVEVA's managed alarm client by setting
-the environment variable `MXGATEWAY_USE_MANAGED_ALARM_ACK=1` on the gateway
-process (workers inherit it; under NSSM, add it to the service environment).
-It is off by default and has no `MxGateway:*` option because it is still
-awaiting live confirmation on the rig. See
+The worker also reads `MXGATEWAY_USE_MANAGED_ALARM_ACK` (inherited from the
+gateway process). Setting it to `1` is meant to route GUID-keyed acknowledges
+through AVEVA's managed alarm client, but a live test (2026-10-18) showed the
+path cannot work as built: the managed client fails to register alongside the
+worker's wnwrap reader and the worker silently falls back to wnwrap. Leave it
+unset. It has no `MxGateway:*` option. See
 [AlarmClientDiscovery](./AlarmClientDiscovery.md) ("Opt-in managed GUID ack").
 
 ### Alarm fallback options