docs: address Task 12 review (supersede stale ack steps, outcome rows)

Claude-Session: https://claude.ai/code/session_016J6isfcgqy4SB2RK3ZvFvT

docs/AlarmProbeFindings.md

@@ -24,14 +24,15 @@ the blocker rather than rediscovering it.
 |---|---|
 | GUID stable across polls and `ALM → RTN` | Answered — yes (2026-05-01 capture in `AlarmClientDiscovery.md`, reconfirmed 2026-08-18) |
 | GUID stable across clear-then-re-raise | Answered 2026-08-18 — **no**, a re-raise mints a new GUID |
-| GUID stable across `UNACK → ACK` | **Open** — the rig cannot be driven into an acknowledged state; 2026-08-18 (third attempt) identifies the reason as the test attribute's `MxSecurityOperate` classification, which no non-interactive ack surface on the rig can satisfy |
+| GUID stable across `UNACK → ACK` | Blocker resolved 2026-10-19 — the rig is driven to `ACK_ALM` by an `AckMsg` write, and the `MxSecurityOperate` classification was not the cause (see "Fourth attempt"); GUID survival across that transition has not been recorded yet |
 | Acknowledge an alarm headless | Answered 2026-10-19 — **an `AckMsg` write as the authenticated operator**; every alarm-client ack is inert (see "Fourth attempt") |
 | `COUNT` = total active vs records-in-reply under a capped fetch | Answered 2026-08-18 — **records in the reply** |
 
 The 2026-08-17 run below is kept because it is the record of the wrong-verb blocker. The
 2026-08-18 run cleared that blocker with `AuthenticateUser` + `WriteSecured` and answered
 two of the three questions; the acknowledge leg is now blocked on something narrower and
-different, described in "Second attempt" and diagnosed in "Third attempt".
+different, described in "Second attempt" and diagnosed in "Third attempt"
+(resolved in the Fourth attempt, 2026-10-19).
 
 ## First attempt (2026-08-17): plain `Write`
 
@@ -450,8 +451,8 @@ snapshot parser reads them for Acknowledge transitions. An unauthenticated write
 therefore acknowledges but leaves no operator in the Historian, which is why the
 gateway requires `operator_user` and authenticates it.
 
-Another actor's `AckMsg` writes on the same day (authenticated as `dohertj2`)
-logged `Operator=dohertj2`, `Domain="."` and that machine's name as the node,
+Another actor's `AckMsg` writes on the same day (authenticated as another
+operator account) logged that account as `Operator`, `Domain="."` and that machine's name as the node,
 which matches the client-name rule. By this date unauthenticated writes to
 `MxSecurityOperate` attributes were also accepted Galaxy-wide on the rig, where
 August refused them with 1008.
@@ -466,7 +467,7 @@ nor the Historian:
 - wnwrap `IwwAlarmConsumer2` on a sole consumer with `SetXmlAlarmQuery` applied
   (list populated, `GetAlarm(0)` returns the row): `AlarmAck` with ids
   0/1/2/3/-1/65536, and `Select(0)` + `AlarmAckSelected`, with operators
-  `TestOperator`, `Administrator` and `dohertj2`. `SelectByGUID` is `E_NOTIMPL`.
+  `TestOperator`, `Administrator` and a third account. `SelectByGUID` is `E_NOTIMPL`.
 - The same calls with `TestAlarm001` temporarily reclassified to
   `MxSecurityFreeAccess` (template and instance, restored afterwards), so the
   security classification is not the cause.