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.

gateway.md

@@ -265,9 +265,10 @@ means "this active set may be incomplete", not "this record is unreliable" —
 it is independent of the subtag-fallback `degraded` field above. It is not
 latched: the first fetch that comes back under the cap is complete, restores
 absence authority, and clears it. Detection remains the record-count heuristic;
-the reply's `ALARM_RECORDS/@COUNT` attribute would make the test exact only if
-it reported the total active count rather than the records in the reply, which
-a live probe could not discriminate (see `docs/AlarmProbeFindings.md`).
+the reply's `ALARM_RECORDS/@COUNT` attribute would have made the test exact only
+if it reported the total active count, and the 2026-08-18 live probe observed it
+reporting the records in the reply instead (see `docs/AlarmProbeFindings.md`), so
+there is no exact alternative.
 
 Forced modes are available via `MxGateway:Alarms:Fallback:Mode`:
 `ForceAlarmManager` disables failover; `ForceSubtag` forces the standby