docs(alarms): stop describing the wnwrap ack as working, and say the re-raise replaces the record

Follow-up to 90331b6. Three comment/prose corrections, no behaviour change.

AcknowledgeByName's comment still said the 6-arg overload "works and reaches the
alarm-history path correctly", which the same commit's own findings contradict in
three other places. It now says what was observed: rc=0 means accepted, not
applied — the 2026-08-18 probe acked a live alarm six ways and the snapshot, the
OPERATOR_NAME field, and the extension's .Acked attribute all stayed put. The -55
tracks the consumer, not the overload. Subscribe's comment gets the same
treatment: "lets AlarmAckByName succeed" becomes "return rc=0".

AlarmProbeFindings.md said the re-raise arrives as "a separate record" alongside
the returned one, which reads as coexistence and is wrong. The snapshot carries
one record per tag: the cap=1024 replies bracketing the re-raise are both
elementCount=3 (one per TestMachine_00{1,2,3}) at an identical 1613 bytes, and the
old GUID is absent from the later one. The re-raise replaces the record, so a
single poll spanning it sees the Clear and the Raise together.

Worker diff verified strictly comment-only; builds x86 on windev, 0W/0E.

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

@@ -194,11 +194,13 @@ public sealed class WnWrapAlarmConsumer : IMxAccessAlarmConsumer
                 ?? throw new ObjectDisposedException(nameof(WnWrapAlarmConsumer));
 
             // Use the IwwAlarmConsumer (v1) prefix-named methods for the
-            // lifecycle. Empirically (live dev-rig 2026-05-01) this is the
-            // only path that lets AlarmAckByName succeed afterwards. The
-            // v2 Initialize/Register/Subscribe methods on the class
-            // succeed (return 0) but acks against that consumer state
-            // return -55.
+            // 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
+            // consumer state return -55. Note rc=0 means the call was
+            // accepted, not that an acknowledgement was applied — see
+            // AcknowledgeByName below and docs/AlarmProbeFindings.md.
             int init = com.IwwAlarmConsumer_InitializeConsumer(DefaultApplicationName);
             if (init != 0)
             {
@@ -345,8 +347,18 @@ public sealed class WnWrapAlarmConsumer : IMxAccessAlarmConsumer
 
         // Empirically (live dev-rig 2026-05-01): the IwwAlarmConsumer2
         // 8-arg AlarmAckByName returns -55 on this AVEVA build (looks like
-        // a stub). The legacy 6-arg IwwAlarmConsumer.AlarmAckByName works
-        // and reaches the alarm-history path correctly. Operator-domain
+        // a stub) and the legacy 6-arg IwwAlarmConsumer.AlarmAckByName
+        // returns 0, which is why the 6-arg overload is the one called here.
+        // A zero return is NOT evidence the acknowledgement was applied: the
+        // 2026-08-18 probe acked a real, freshly raised alarm six ways and
+        // watched the snapshot stay UNACK_ALM, OPERATOR_NAME stay empty, and
+        // the alarm extension's own .Acked attribute stay False for 16 s after
+        // each call. On that rig the ack is accepted and then inert, and the
+        // -55 tracks the consumer rather than the overload — both overloads
+        // return -55 against a SetXmlAlarmQuery-applied consumer and 0 against
+        // the ack-only one. Whether any wnwrap ack reaches the alarm-history
+        // path is therefore unverified; see docs/AlarmProbeFindings.md.
+        // Operator-domain
         // and operator-full-name fields are accepted by the proto contract
         // for forward-compat but are not propagated to AVEVA today —
         // wrapped in the 6-arg call so domain/full-name go to the