docs: alarm acknowledgement writes AckMsg as the authenticated operator

Claude-Session: https://claude.ai/code/session_016J6isfcgqy4SB2RK3ZvFvT

src/ZB.MOM.WW.MxGateway.Server/appsettings.json

@@ -88,7 +88,8 @@
       "DefaultArea": "",
       "ReconcileIntervalSeconds": 30,
       "PollIntervalMilliseconds": 500,
-      "MaxAlarmsPerFetch": 1024
+      "MaxAlarmsPerFetch": 1024,
+      "AckClientName": "MxGateway"
     }
   }
 }

src/ZB.MOM.WW.MxGateway.Worker/MxAccess/WnWrapAlarmConsumer.cs

@@ -202,14 +202,14 @@ public sealed class WnWrapAlarmConsumer : IMxAccessAlarmConsumer
 
             // Use the IwwAlarmConsumer (v1) prefix-named methods for the
             // lifecycle. Empirically (live dev-rig 2026-05-01, reconfirmed
-            // 2026-08-18) this is the only path that lets AlarmAckByName
-            // return rc=0 afterwards. The v2 Initialize/Register/Subscribe
-            // methods on the class succeed (return 0) but acks against that
+            // 2026-08-18) the v1 path is the one that leaves the consumer in
+            // a usable state: the v2 Initialize/Register/Subscribe methods on
+            // the class succeed (return 0) but later calls against that
             // consumer state return -55. The v1 prefix path is what
-            // WIN-911-style code uses against the same wnwrap library.
-            // Note rc=0 means the call was
-            // accepted, not that an acknowledgement was applied — see
-            // docs/AlarmProbeFindings.md. Acks now go through AlarmAckWriter.
+            // WIN-911-style code uses against the same wnwrap library. This
+            // consumer only reads the alarm snapshot; acknowledgements go
+            // through AlarmAckWriter, not through wnwrap (see
+            // docs/AlarmProbeFindings.md).
             int init = com.IwwAlarmConsumer_InitializeConsumer(DefaultApplicationName);
             if (init != 0)
             {
@@ -615,10 +615,10 @@ public sealed class WnWrapAlarmConsumer : IMxAccessAlarmConsumer
     ///         place under its original GUID and the re-raise replaced it with a
     ///         freshly minted one. That is the intended reading — the old
     ///         instance ended and a new one began — so the diff emits a Clear
-    ///         plus a Raise, which is what happened. The acknowledge leg remains
-    ///         assumed rather than observed: on the dev rig every ack surface is
-    ///         inert (<c>AlarmAckByName</c> returns 0 and nothing moves), so no
-    ///         record can be driven into an acknowledged state — see
+    ///         plus a Raise, which is what happened. Every alarm-client ack surface
+    ///         is inert on the dev rig (it returns 0 and nothing moves), so
+    ///         acknowledgements go through the AckMsg writer; an AckMsg write
+    ///         moves the record to <c>ACK_ALM</c> (observed 2026-10-19) — see
     ///         <c>docs/AlarmProbeFindings.md</c>.
     ///     </para>
     /// </remarks>