runbook: correct the WEBHOOK_TOKEN rotation state (rotated 2026-10-27; URL match unverified)

operator-token-runbook.md

@@ -60,9 +60,15 @@ cutover completed 2026-10-28 (`ADMIN_TOKEN_LEGACY=0`), verified on the wire:
 - **Rotating `ADMIN_TOKEN` touches THREE places** — the portal env (shared by the
   app and the scheduler addon), the admin panel's separate copy, and the agent's
   `~/.hermes/.env`. Miss one and that caller 403s silently.
-- **Rotating `WEBHOOK_TOKEN` needs Open Collective admin access**, because the
-  value lives in the webhook URL on the collective — the same blocker as moving
-  `OC_PERSONAL_TOKEN` (below) to a co-op-owned account.
+- **`WEBHOOK_TOKEN` was rotated on 2026-10-27**, as a precaution after a test
+  handled the URL. Rotating it *again* means updating BOTH the portal env and the
+  webhook URL configured on the collective, which needs Open Collective admin
+  access — the same blocker as moving `OC_PERSONAL_TOKEN` (below) to a
+  co-op-owned account.
+- **Unverified:** whether the collective's webhook URL was updated in step with
+  that rotation. The route compares the URL token against the env var, so a
+  mismatch makes OC's deliveries 401 and new-member provisioning waits for the
+  nightly sweep (delayed, not lost). Treat the first real OC event as the test.
 - **No caller may fall back from `ADMIN_TOKEN` to `WEBHOOK_TOKEN`.** The legacy
   token 403s, so a fallback turns "unset" into a confusing mid-run failure
   instead of a clear abort.