docs(alarms): second wnwrap probe attempt — secured-write verb unblocked the rig, answering @COUNT and the re-raise GUID leg

AuthenticateUser("Administrator", "") + WriteSecured raises the alarm UDAs that
plain Write could not touch (SecurityError detail=1008), so the 2026-08-17 blocker
was the verb, exactly as that run's own Unblocking list predicted.

Two of the three open questions are now observed rather than assumed:

- ALARM_RECORDS/@COUNT reports the records in the reply, not the total active
  count. With three alarms active it read 1 at cap 1 and 2 at cap 2. There is no
  exact truncation signal to switch to, so IsTruncatedFetch's conservative rule is
  the design rather than a placeholder — behaviour unchanged, only the comments.
- Clear-then-re-raise mints a new GUID; the ALM->RTN leg keeps its GUID
  (reconfirming the 2026-05-01 capture). ComputeTransitions already reads the
  re-raise correctly as one instance ending and another beginning.

The acknowledge leg stays unobserved for a narrower reason: every wnwrap ack
surface is inert on this rig. AlarmAckByName returns 0 from the ack-only consumer
and -55 from the SetXmlAlarmQuery-applied one, for both the 6-arg and 8-arg forms,
and neither the snapshot STATE, OPERATOR_NAME, nor the extension's own .Acked
attribute moves. That corrects AlarmClientDiscovery.md, which read the zero return
as a working ack.

Comment- and prose-only; no behaviour change. The three throwaway probes ran from
the windev CI clone and were deleted; that clone is a clean tree at ab3ff16.

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

@@ -429,10 +429,12 @@ public sealed class WnWrapAlarmConsumer : IMxAccessAlarmConsumer
         // have exactly that many active alarms. Treat the ambiguous case as
         // truncated: the false-positive cost is a snapshot that stays stale for
         // one poll, the false-negative cost is every alarm past the cap reading
-        // as cleared. (The reply's ALARM_RECORDS/@COUNT attribute is a
-        // candidate exact signal, but only if it reports the total rather than
-        // the records in the reply — untested on a live rig, see
-        // docs/AlarmProbeFindings.md.)
+        // as cleared. (The reply's ALARM_RECORDS/@COUNT attribute was the
+        // candidate exact signal; the 2026-08-18 live probe settled it — with
+        // three alarms active, @COUNT read 3, 1, and 2 at caps 1024, 1, and 2,
+        // matching the records in the reply every time. It reports the reply,
+        // not the total, so it cannot tell a capped fetch from a complete one.
+        // See docs/AlarmProbeFindings.md.)
         bool truncated = IsTruncatedFetch(fetchedRecordCount, maxAlarmsPerFetch);
 
         IReadOnlyList<MxAlarmTransitionEvent> transitions =
@@ -491,12 +493,14 @@ public sealed class WnWrapAlarmConsumer : IMxAccessAlarmConsumer
     ///     offers no confirmed "more available" flag, so a reply at exactly the
     ///     cap is indistinguishable from a galaxy that happens to hold exactly
     ///     that many active alarms; both are treated as truncated. The reply
-    ///     root carries an <c>ALARM_RECORDS/@COUNT</c> attribute that would make
-    ///     the test exact if it reported the total active count rather than the
-    ///     records in this reply; a live probe could not discriminate the two
-    ///     (see <c>docs/AlarmProbeFindings.md</c>), so the count is deliberately
-    ///     not trusted here. Exposed as <c>internal static</c> so the rule is
-    ///     unit-testable without the wnwrapConsumer COM object.
+    ///     root carries an <c>ALARM_RECORDS/@COUNT</c> attribute that would have
+    ///     made the test exact had it reported the total active count; the
+    ///     2026-08-18 live probe observed it tracking the records in the reply
+    ///     instead (three alarms active returned @COUNT 1 at cap 1 and 2 at cap
+    ///     2), so it carries no "more available" information and is deliberately
+    ///     not trusted here (see <c>docs/AlarmProbeFindings.md</c>). Exposed as
+    ///     <c>internal static</c> so the rule is unit-testable without the
+    ///     wnwrapConsumer COM object.
     /// </summary>
     /// <param name="fetchedRecordCount">ALARM records the reply carried.</param>
     /// <param name="maxAlarmsPerFetch">The cap that was passed to the fetch.</param>
@@ -660,10 +664,17 @@ public sealed class WnWrapAlarmConsumer : IMxAccessAlarmConsumer
     ///         <em>instance</em> rather than the state it is in: a re-minted
     ///         GUID would read as the old alarm vanishing and a new one
     ///         appearing, i.e. a spurious Clear plus a spurious Raise. Live
-    ///         capture confirms stability across the active→returned leg only
-    ///         (<c>docs/AlarmClientDiscovery.md</c>); the acknowledge leg and
-    ///         re-raise-after-clear are assumed, not observed, because the dev
-    ///         rig's alarm attributes reject unauthenticated writes — see
+    ///         capture confirms stability across the active→returned leg
+    ///         (<c>docs/AlarmClientDiscovery.md</c>, reconfirmed 2026-08-18).
+    ///         Re-raise-after-clear was observed on 2026-08-18 and does
+    ///         <em>not</em> reuse the GUID: clearing left the returned record in
+    ///         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
     ///         <c>docs/AlarmProbeFindings.md</c>.
     ///     </para>
     /// </remarks>