memory: gitea corviduo/ledger renamed to corviduo/svos; svos Heimdall mint now open

Rename executed on the operator's direct authorization. Repo id 70 unchanged.
Redirect verified by measurement rather than by citing upstream #807: web and
API paths both 301, and `git ls-remote` against the old URL warns, follows, and
returns HEAD b48a11ca5183. Existing clones keep working.

Recorded as a standing hazard that the old path is now burned — a repo created
at corviduo/ledger kills the redirect silently.

Also opens the Heimdall item ledger-dev had been holding as "awaiting infra-ops"
without ever having sent it, including the deletion-ordering trap that makes
retiring the old key first unrecoverable.

persistent-memory.md

@@ -170,9 +170,29 @@ below is a live commitment or a known-open risk._
   their repo, their call; answered that 1.26.1 writes a `repo_redirect` on a
   same-org repo rename (upstream #807), that org/user renames do NOT redirect
   (#9531), that the redirect dies if anything re-creates the old path, and that the
-  repo and org both carry 0 webhooks. Handle `ledger-dev` → `svos-dev` is an
+  repo and org both carry 0 webhooks. **Gitea rename EXECUTED 2026-09-05** on the
+  operator's direct authorization: `corviduo/ledger` → `corviduo/svos`, repo id 70
+  unchanged. Redirect verified by measurement — web and API both 301, and
+  `git ls-remote` on the old URL warns-and-follows to HEAD b48a11ca5183. ⚠ **The
+  name `corviduo/ledger` is now burned**: the redirect dies silently the moment
+  anything creates a repo at that path. Handle `ledger-dev` → `svos-dev` is an
   operator action at the post office.
 
+- **OPEN, with ledger-dev: mint a `svos` Heimdall user + API key.** Never actually
+  asked of me until 2026-09-05 (it sat in their runbook as "awaiting infra-ops"
+  while addressed to worldtree-dev, who hold no key material). Constraints: string
+  `svos` verbatim (WT tier 3 admits only `^[a-z][a-z0-9-]{2,63}$`, INV-181-15);
+  **keep the existing `ledger` key LIVE**, do not revoke. Ordering is load-bearing —
+  `DELETE /agents/{agent_id}` refuses any caller that is not the row's owner, so
+  `ledger:miranda` can ONLY be deleted with the `ledger` key; retire it first and
+  the stale row outlives the ability to remove it, holding a live
+  `agents.call:ledger:miranda` grant that nothing reaps (the 24h sweep only touches
+  soft-deleted rows, and soft-deletion comes from revocation, never disuse). So:
+  mint new → they cut over and verify → delete the agent with the OLD key → then
+  retire it. Precedent for who mints: msg 401, worldtree-dev routed the pewpewstudio
+  key request TO infra-ops. I hold only the PERSONAL admin token (:8081); which
+  deployment `ledger` lives on is not yet established. Surfaced to the operator.
+
 - **Open commitment to vastblue-dev:** a dedicated CI runner, gated on their first
   client-premises release cut (U10, unscheduled). Ping expected when U10 is scheduled.