memory: svos cutover verified; record the cutover-destroys-the-old-key foot-gun

Cutover landed clean — a 201 define rather than 409/PATCH, which is what proves
the new identity is actually in use. No plan- or rate-limit errors, so the
deliberately unset tier is compatible and is explicitly not to be set.

The durable lesson is the ordering trap ledger-dev caught: any credential
cutover whose OLD key is required for a later cleanup is destroyed by the
obvious housekeeping right afterwards. Re-vaulting the post-cutover env.sh
would have overwritten the only convenient copy of the key that can delete
ledger:miranda. Verified their preserved copy is genuinely that key by matching
its trailing 8 characters against the live key suffix rather than trusting the
label.

Also corrects this file's own claim that backfill was the right re-vault tool —
it rescans the whole box and is the slow path for a single known item.

persistent-memory.md

@@ -201,12 +201,34 @@ below is a live commitment or a known-open risk._
   delivery is confirmed. **The cutover itself — pasting the value into env.sh,
   flipping `worldtree.user_id` from `ledger` to `svos`, registering
   `svos:miranda`, restarting the service — is WITH THE OPERATOR**, not with me;
-  they will not do it off a peer message. They will `secret backfill` afterwards
-  rather than asking for a manual re-put. **OPERATOR RULING 2026-09-05:
+  they will not do it off a peer message. **CUTOVER DONE + VERIFIED 2026-09-05**:
+  `POST /agents/define` returned **201, not 409** — the load-bearing signal that
+  they are genuinely on the new identity rather than silently still on the old
+  one — then clean session create, turn, bifrost handshake and tool-call. **No
+  plan- or rate-limit errors, so the unset tier is compatible and is NOT to be
+  set** (they asked explicitly; it stays a watch item to fix on report, never by
+  guess). Incidentally confirmed the bifrost allowlist really is per-deployment
+  (host:port), not per-consumer — Worldtree reached back to their untouched
+  endpoint under the new consumer_id. `env.sh` re-vaulted, sha 8a225c002072.
+  ⚠ **`secret backfill` was the WRONG tool for one known item** — it rescans every
+  `~/development/*/{env.sh,.env}` and had not reached svos after three minutes;
+  targeted `put` is the fast path, backfill is for catching drift across the box.
+  **OPERATOR RULING 2026-09-05:
   worldtree-dev owns code only, no ops — key material is infra-ops's.** The global
   `~/.claude/CLAUDE.md` line routing "Heimdall scopes (Worldtree auth) →
   worldtree-dev" was corrected in place the same day on operator instruction.
 
+- ⚠ **FOOT-GUN, generalises past this rename: a credential cutover whose OLD key
+  is required for a later cleanup is destroyed by the natural housekeeping motion
+  right after cutover.** Re-vaulting the post-cutover `env.sh` would have
+  overwritten the last convenient copy of the old `ledger` key value — the only
+  credential that can ever delete `ledger:miranda`. ledger-dev caught it and
+  preserved the value first at
+  `nh3-dev/development/svos/worldtree-api-key-ledger-legacy` (sha d44c2c1a651b);
+  their step 8 ends by deleting that item. **I verified it is genuinely the live
+  key** rather than trusting the label: its last 8 chars are `e68a5170`, matching
+  the `ledger` key's suffix (key_id b38932f5).
+
 - **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);