fix(runtime): #869 review round 3 — key a native-ack revert to the ack that failed

A pending local ack can outlive its own delivery (sources that send no
Acknowledge back; a Clear now only carries it through), so a later failed
re-ack — or a stale Galaxy confirmation timing out after the alarm re-occurred
and was acked again — could revert an ack it does not own. MarkAcknowledged
now issues a sequence (0 when the ack changed nothing), carried on
RouteAlarmAck and echoed on AlarmAckFailed; TryRevertAcknowledge reverts only
on a matching sequence.

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

docs/AlarmTracking.md

@@ -477,7 +477,9 @@ from the scripted `AlarmCommandRouter`:
    reverted: a driver transition projected since then that states the ack
    (Acknowledge, ActiveAcknowledged, or an un-acking Raise/Retrigger/
    InactiveUnacknowledged) is authoritative; one that only carries the ack
-   through (a Clear, a same-message Raise) leaves it revertible (#869). A
+   through (a Clear, a same-message Raise) leaves it revertible (#869) — and
+   only by a failure of THAT acknowledge: the revert is keyed to the sequence
+   `MarkAcknowledged` issued, echoed on `RouteAlarmAck` / `AlarmAckFailed`. A
    refusal the driver can decide without I/O (Galaxy, with no fallback ack
    account: an anonymous session, or a keyed session whose key the cached
    `GalaxyAckIdentityDirectory` knows has no ack identity — #765) is instead