docs(probe): close superseded unblock bullet, hedge the summary, evidence gobject_id, ack-caveat in RPC docs

docs/AlarmProbeFindings.md

@@ -258,7 +258,9 @@ MXAccess-side entry point and the wnwrap-side entry point is inert.
   requirement that the wnwrap consumer, which passes an operator *name* string and no
   authenticated identity, cannot meet. If so, ack over wnwrap is not merely untested here
   but unavailable by configuration, and the gateway's `AcknowledgeByName` path needs the
-  same treatment on any customer galaxy configured that way.
+  same treatment on any customer galaxy configured that way. (Answered by the Third attempt
+  below — enforced by the alarm attribute's `MxSecurityOperate` security classification, an
+  engine-level write-security setting, not a separate `alarmmgr`-side ack policy.)
 - If neither lands, the acknowledge leg stays assumed. It is worth restating that this is a
   documentation gap, not a correctness one: a re-minted GUID on acknowledge would produce a
   spurious Clear plus a spurious Raise, which is the same shape the now-observed re-raise
@@ -284,7 +286,12 @@ notes referenced elsewhere in this repo are **not present on this box** (`Test-P
 ### The test attribute is classified `MxSecurityOperate`
 
 UDA security classification lives in `dynamic_attribute.security_classification`, keyed by
-`gobject_id` — for the `$TestMachine` template that is `1055`:
+`gobject_id`. For the `$TestMachine` template that is `1055`:
+
+```
+SELECT gobject_id, tag_name, hierarchical_name FROM gobject WHERE gobject_id=1055;
+1055|$TestMachine|$TestMachine
+```
 
 ```
 attribute_name  | security_classification | mx_attribute_category
@@ -374,8 +381,10 @@ statements and both matter:
 - The wnwrap ack path is unavailable on this rig as configured, for an identified reason
   rather than an unknown one. This is a real finding for the gateway: `AcknowledgeByName`
   will behave the same way — accepted, inert — on any customer galaxy whose alarmed
-  attributes carry a non-free-access security classification. It is worth noting in the
-  alarm client's documentation that a silent `rc=0` is not proof of acknowledgement.
+  attributes carry a non-free-access security classification (inferred from the mechanism —
+  no `AlarmAckByName` overload can carry a credential — not confirmed by relaxing the
+  classification and re-testing; see "What a human would need to do"). It is worth noting in
+  the alarm client's documentation that a silent `rc=0` is not proof of acknowledgement.
 - Whether wnwrap re-mints the record GUID on `UNACK_ALM → ACK_ALM` is still unobserved, and
   after three attempts it stays assumed. As the second attempt already noted, this remains
   a documentation gap rather than a correctness one: a re-minted GUID produces a spurious