docs: document inbound alarm ack/shelve (AlarmAck gate, alarm-commands, AdminUI/CLI) + remove scratch files

Records T17-T22 as shipped: RoleCarryingUserIdentity, Part 9 method handlers gated on AlarmAck
role, alarm-commands DPS topic, ScriptedAlarmHostActor dispatch, WriteAlarmCondition delta-gate,
AdminUI /alerts Acknowledge/Shelve/Unshelve buttons via AdminOperationsActor singleton, and
Client.CLI ack/confirm/shelve commands. Corrects stale "Not started" / "Partial" entries in
phase-7-status.md (Stream G OPC UA method binding row and C.6 row and Gap 1 body) and adds
the alarm-commands topic to Runtime.md. Removes untracked scratch files resume.md and pending.md.

docs/AlarmTracking.md

@@ -77,7 +77,7 @@ comment + original raise time) and arrive lower-latency (no
 publishing-interval delay on the sub-attribute reads), so they win
 the dedup.
 
-## Acknowledge routing
+## Acknowledge routing — Galaxy / driver alarms
 
 `DriverNodeManager` picks the acknowledger when registering each
 condition (PR B.3 logic):
@@ -99,6 +99,60 @@ already validates the session's `AlarmAck` role before dispatching,
 so the gateway-side ack RPC only sees authenticated, authorised
 calls.
 
+## Inbound operator ack/shelve — scripted alarms
+
+Scripted alarms use a separate inbound path that converges on the
+`alarm-commands` DPS topic. Two surfaces route onto this topic:
+
+### OPC UA Part 9 method path (external OPC UA clients)
+
+`OtOpcUaNodeManager` wires the Part 9 condition methods (Acknowledge /
+Confirm / AddComment / OneShotShelve / TimedShelve / Unshelve) on each
+scripted-alarm `AlarmConditionState` node. Every call is **gated on the
+`AlarmAck` LDAP role** — fail-closed: sessions with no role or without
+`AlarmAck` group membership receive `BadUserAccessDenied` immediately.
+The LDAP-resolved role set is carried past `OpcUaApplicationHost` by
+`RoleCarryingUserIdentity` (a `UserIdentity` subclass), making it
+readable inside the method handler at dispatch time.
+
+On allow, the handler publishes a `Commons.OpcUa.AlarmCommand` onto the
+`alarm-commands` DPS topic. The node manager is Akka-free; the dispatch
+action is a settable `Action<AlarmCommand>` injected at boot by the
+hosted service.
+
+`OnTimedUnshelve` (the SDK's automatic unshelve timer) bypasses the
+operator gate — it is system-initiated.
+
+`WriteAlarmCondition` fires the Part 9 condition event only when the
+incoming state differs from the node's current live state (delta-gate),
+preventing the double-emit that would otherwise occur when the SDK
+auto-applies the acked state and the engine re-projection fires a
+duplicate event immediately after.
+
+### AdminUI path
+
+The `/alerts` page shows per-row **Acknowledge / Shelve / Unshelve**
+buttons gated by the `DriverOperator` AdminUI policy. These route
+through the `AdminOperationsActor` cluster singleton
+(`AcknowledgeAlarmCommand` / `ShelveAlarmCommand`), which publishes onto
+the same `alarm-commands` topic. The singleton handles cross-node
+routing — the command always reaches the driver-role node owning the
+engine regardless of which AdminUI instance the operator is on.
+
+### ScriptedAlarmHostActor dispatch
+
+`ScriptedAlarmHostActor` subscribes to the `alarm-commands` topic,
+ownership-filters each command (each node only acts on its own alarms),
+and dispatches to the matching `ScriptedAlarmEngine` operation
+(`AcknowledgeAsync` / `ConfirmAsync` / `OneShotShelveAsync` /
+`TimedShelveAsync` / `UnshelveAsync` / `EnableAsync` / `DisableAsync` /
+`AddCommentAsync`). The engine's existing `OnEvent` callback handles
+the OPC UA node update — no explicit re-projection is required.
+
+The AdminUI `/alerts` Shelve flow was live-verified on docker-dev
+2026-06-11: singleton → topic → host actor → engine → "Shelved" status
+reflected on `/alerts` with the operator identity threaded through.
+
 ## Historian write-back (non-Galaxy alarms)
 
 Scripted alarms (and any future non-Galaxy `IAlarmSource` like