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/AlarmClientDiscovery.md

@@ -764,6 +764,17 @@ The v2 8-arg method returns -55 on this AVEVA build regardless of
 operator-identity inputs — looks like a stub. The v1 6-arg method
 works. Production `WnWrapAlarmConsumer.AcknowledgeByName` calls the
 6-arg overload and discards the proto's `domain` + `full_name` fields.
+
+**Correction, 2026-08-18** (`docs/AlarmProbeFindings.md`). Both halves
+of the paragraph above are narrower than they read. The -55 tracks the
+*consumer*, not the overload: against the `SetXmlAlarmQuery`-applied
+reader both the 6-arg and 8-arg forms return -55, and against the
+ack-only consumer both return 0. And "works" means "returns 0" only —
+a probe that raised a real alarm and then acked it six ways 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 this rig the wnwrap ack is accepted and then inert, so a zero
+return code must not be read as an applied acknowledgement.
 The proto contract keeps the 8 fields for forward compatibility if
 AVEVA fixes the v2 method later.