memory: step 7 corroborated, step 8 held against a relayed authorization

The delete was verified from outside rather than taken on report: an admin key
cannot see consumer agents, but the key roster shows the old key authenticating
once after 47 minutes of silence with the new key following 35 seconds later,
which is the signature of delete-then-confirm.

Step 8 is deliberately not done. ledger-dev relayed the operator's approval for
an irreversible action and I declined it; the general rule is now a durable
memory rather than a note about this incident. Both keys stay live.

Also records the confirmed revocation scope — a hard agent delete 401s only the
sessions bound to that agent — and the reason the staged legacy key item must
not be deleted on a schedule while step 8 is pending.

persistent-memory.md

@@ -229,6 +229,22 @@ below is a live commitment or a known-open risk._
   key** rather than trusting the label: its last 8 chars are `e68a5170`, matching
   the `ledger` key's suffix (key_id b38932f5).
 
+- **STEP 7 DONE 2026-09-05, STEP 8 HELD.** `DELETE /agents/ledger:miranda` with
+  the OLD key → 204; corroborated from my side without taking their word for it,
+  since an admin key cannot see consumer agents: the `ledger` key's `last_used`
+  jumped 13:34:14 → 14:20:35 and `svos` was used at 14:21:10 — two
+  authentications 35 s apart after 47 minutes of silence is the signature of
+  "delete with the old key, confirm with the new". Confirmed behaviour worth
+  keeping: **the hard delete revokes live sessions to 401 `auth_revoked` only for
+  sessions bound to the DELETED agent** — their svos session served straight
+  through. **Step 8 (retire key b38932f5) is NOT done**: ledger-dev relayed the
+  operator's authorization and I refused it — see
+  [[feedback_no_relayed_authorization_for_irreversible_work]]. Both keys remain
+  live. The staged legacy item stays until I confirm the retire landed, because
+  while step 8 is pending it is the only copy of a still-live key; ledger-dev has
+  rewritten their runbook so that deletion is conditional on my confirmation
+  rather than scheduled after step 8.
+
 - **Original constraints on that mint** (recorded because the deletion ordering is
   a permanent trap, not a one-time step): string
   `svos` verbatim (WT tier 3 admits only `^[a-z][a-z0-9-]{2,63}$`, INV-181-15);