deploy(althing): post office to 3.6.0 — handle delete/retire verbs go live

The tools had been on 3.6.0 while the container sat on 3.0.0 for seven days, so
the operator verbs failed with "no tool named delete_handle" — they live in the
post office, not the client.

Image built on nh3-dev from a clean tree at 4d26226 and pushed under the
claude-bot namespace; the compose pin moves to the new digest rather than
floating on the tag, since this container is the fleet's whole message bus.

The backup procedure this file documents earned itself again: at stop time the
database was 23.8 MB with a 5.9 MB WAL beside it, so a plain copy would have
produced a database that opens cleanly, smokes green, and is missing the day's
mail. Stop, explicit checkpoint to a zero-byte WAL, copy, then verify counts on
both sides — 76 handles, 995 messages, 1022 recipients, integrity ok.

Post-deploy the same counts came back with handles.retired_at present, and the
memory cap and OOM guard were confirmed by `docker inspect` rather than by
reading the yaml, which is what that file asks for and the only check that can
tell a working cap from a decorative one.

Bus down about four minutes.

persistent-memory.md

@@ -439,9 +439,25 @@ below is a live commitment or a known-open risk._
   `retire`, and `declare` from 3.5.0) live in the post office, so they fail with
   "no tool named ..." until the container carries 3.6.0. Schema gains
   `handles.retired_at` via the idempotent `_ADDED_COLUMNS` path, so the live store
-  upgrades itself on first start — no manual migration. **Not rebuilt: it is a
-  fleet-wide bus restart and wants the operator's nod.** It also blocks the
-  pending `ledger-dev` → `svos-dev` rename, which needs `declare`.
+  upgrades itself on first start — no manual migration. **REBUILT AND DEPLOYED
+  2026-09-05** on operator authorization: image
+  `claude-bot/althing-post-office:3.6.0@sha256:13158835488a8ec04f990c97c4f4c68f1d923b12494319cf07392552e68f8a78`,
+  built on nh3-dev from a clean tree at `4d26226`, pushed to the gitea registry
+  under the **claude-bot** namespace (not `vh` — package namespaces are owned).
+  **Bus down ~4 minutes, 09:35–09:39 PDT.**
+  **The backup was taken the way the compose file says to, and it mattered:** at
+  stop time `post_office.db` was 23.8 MB with a **5.9 MB WAL** — copying the .db
+  alone would have silently lost the day's mail. Stop → `PRAGMA
+  wal_checkpoint(TRUNCATE)` (WAL → 0 bytes) → copy → verify. Backup at
+  `nh3-docker:/var/backups/althing/post_office.db.pre-3.6.0-20260905`, integrity
+  `ok`, counts identical on both sides (handles 76, messages 995, recipients
+  1022). ⚠ **Reading a WAL-mode SQLite backup read-only needs `?immutable=1`, not
+  `?mode=ro`** — `mode=ro` still wants to create a `-shm` and dies with "attempt to
+  write a readonly database". Post-deploy: same counts, `handles.retired_at`
+  present, `retired 0`, and `mem=536870912` / `oom=-500` verified by `docker
+  inspect` rather than by reading the yaml, per that file's own warning.
+  `althing-operator` now offers `declare | delete | retire`, which unblocks the
+  pending `ledger-dev` → `svos-dev` rename.
 
 ## Recent decisions
 

stacks/althing-post-office/compose.yaml

@@ -51,7 +51,7 @@ services:
     # Digest-pinned, not tag-floating: `:3.0.0` is a mutable pointer on a registry
     # anyone can re-push, and this container is the fleet's whole message bus. The
     # tag is kept alongside the digest purely so a human can read what it is.
-    image: gitea.phasefinal.com/claude-bot/althing-post-office:3.0.0@sha256:410fed41fa049c41cf83577fd2e49831ea1959ca50b597a8bd35a548e267cf01
+    image: gitea.phasefinal.com/claude-bot/althing-post-office:3.6.0@sha256:13158835488a8ec04f990c97c4f4c68f1d923b12494319cf07392552e68f8a78
     container_name: althing-post-office
 
     # ─── Host networking, so the bind guard keeps working ────────────