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.

docs/DesignDecisions.md

@@ -226,13 +226,14 @@ payload carries the flag as well because a prefix filter (or an empty galaxy) ca
 leave zero records, and a truncated fetch with nothing to report still has to say
 so.
 
-The **detection heuristic is unchanged**: `IsTruncatedFetch` remains
-`fetchedRecordCount >= maxAlarmsPerFetch`. The live probe run for this work could
-not verify whether `ALARM_RECORDS/@COUNT` reports the total active count or only
-the records in the reply (`docs/AlarmProbeFindings.md`), and an exact-looking
-signal derived from an unverified attribute is worse than an honest heuristic —
-it would read as precise while being wrong in the one direction that matters.
-Switching to `@COUNT` stays blocked on probe evidence.
+The **detection heuristic is unchanged, and now permanently**: `IsTruncatedFetch`
+remains `fetchedRecordCount >= maxAlarmsPerFetch`. The 2026-08-18 probe settled
+what the earlier run could not: with three alarms active, `ALARM_RECORDS/@COUNT`
+read 1 at a cap of 1 and 2 at a cap of 2, so it reports the records in the reply
+rather than the total active count (`docs/AlarmProbeFindings.md`). There is no
+exact signal to switch to — `@COUNT` cannot distinguish a capped fetch from a
+complete one — so the heuristic is the design rather than a placeholder waiting
+on evidence.
 
 The flag is **not latched**. It is replaced by each fetch's verdict, so the first
 sub-cap fetch clears it, and `GatewayAlarmMonitor.ClearCache` drops it with the