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.

docs/AlarmProbeFindings.md

@@ -186,8 +186,14 @@ after-reraise    TAG=TestMachine_001.TestAlarm001 GUID=2394FEAA94774154AAA97C3AC
 
 Two facts, one confirming and one new. The `ALM → RTN` leg holds its GUID, reconfirming the
 2026-05-01 capture against a write-driven rather than script-driven transition. The re-raise
-does not: the returned record keeps the old GUID and the new active condition arrives as a
-separate record under a fresh one.
+does not: the record comes back under a GUID that has never been seen before.
+
+The two records do **not** coexist — the snapshot carries one record per tag, and the
+re-raise replaces the returned record rather than joining it. Both fetches above are the
+full `cap=1024` reply, byte-identical in length (1613) at `@COUNT=3`/`elementCount=3`, the
+three records being one per `TestMachine_00{1,2,3}`; `72B84A6E…` is simply absent from the
+later one. So a single poll spanning the re-raise sees the old GUID disappear and the new
+one appear together.
 
 That is the correct reading for `ComputeTransitions` rather than a problem for it. The old
 GUID leaving the active set is a real Clear and the new GUID is a real Raise, because they