docs: runbook section 5 lists a bot's token ids as svc (sage)

Darkwing's probe-s7f: svc-$BIZ revokes one bot token (204, then 401);
the owner gets 403. A plain GET /tokens shows only svc's own tokens, so
rotation names GET /tokens?owner_id=<bot id> for an old id. Decision 68
records the resolution.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/guides/slice-1-identities.md

@@ -354,7 +354,12 @@ role. The stack never writes this file.
   definitions in section 3. Mint a new token for the same bot, update
   `expires` in the business file, and restart the broker. Revoke the
   old token while the svc header still exists:
-  `svc -X DELETE "$VK/api/v2/tokens/<old id>"`. Then finish with section
+  `svc -X DELETE "$VK/api/v2/tokens/<old id>"`. A revoke hits that one
+  token, and it gets 401 on its next request. `mint` printed the old
+  id. If you didn't keep it, list the bot's tokens as `svc-$BIZ`:
+  `svc "$VK/api/v2/tokens?owner_id=<bot id>" | jq -c '.[] | {id, title, expires_at}'`.
+  A plain `GET /tokens` lists only svc's own tokens, which is none, and
+  the owner's account gets 403 on the revoke. Then finish with section
   4's `rm -f`, which deletes the header. The broker refuses to
   start with a token past its `expires`, and it treats any 401 as a
   refusal, never a retry.

docs/plans/2026-09-26_lead-decisions.md

@@ -1239,3 +1239,10 @@ which stay with him. Each item names who decided it and what happened.
       an estate rule. Jason is away 10-10, so the runbook's Vikunja
       sections run on 10-11 at the earliest, depending on T236. R20 is
       confirmed to Mos: Sage is the stack's PM and Darkwing its Lead.
+    - Resolved (Darkwing, `probe-s7f.mjs`, probes.md section R):
+      `svc-$BIZ` revokes its bot's token with `DELETE /tokens/{id}`
+      (204, then 401 on the next request). The bot's other tokens keep
+      working. The owner's revoke gets 403. The runbook's section 5 now
+      names `GET /tokens?owner_id=<bot id>` as svc for finding an old
+      id. The async update lag has an upper bound of 5 s under load,
+      inside S3's 60 s overlap window (section U).