memory: handle retire is reversible — re-declaring revives it, history intact

Changes the risk profile of the pending ledger-dev -> svos-dev rename, so it
belongs in memory rather than only in the thread: retire is the correct verb
(delete refuses any handle carrying mail) and it can be undone by declaring the
name again.

Also records that both deploy findings landed in althing's own INSTALL.md,
where they sit beside the journal_mode=WAL setting that causes them rather than
in a procedure doc that only describes working around it.

persistent-memory.md

@@ -459,6 +459,18 @@ below is a live commitment or a known-open risk._
   `althing-operator` now offers `declare | delete | retire`, which unblocks the
   pending `ledger-dev` → `svos-dev` rename.
 
+- **Handle `retire` is REVERSIBLE — re-declaring the name revives it, history
+  intact** (forseti smoked it against the live bus 2026-09-05). That matters for
+  the pending `ledger-dev` → `svos-dev` rename: `retire` is the right verb (delete
+  refuses any handle that has mail, naming both counts — `delete forseti` was run
+  against production and correctly refused at 53 sent / 81 addressed, which is
+  safe to try precisely because refusing IS the behaviour), and it can be undone
+  by declaring the name again. Lower stakes than "retire" sounds.
+  Both of my deploy findings — the naive-copy WAL trap and `?immutable=1` — are
+  now in althing's own `deploy/INSTALL.md` (`d6f4fb5`) under a new
+  "Backing up the store" section, on the reasoning that they are properties of
+  the project's `journal_mode=WAL` choice rather than of my procedure.
+
 ## Recent decisions
 
 - `[2026-09-05]` **A peer's "2.7x serving-stack effect" was a coin flip — the operator rejected it on instinct and the arithmetic backed him.** Each floor was `|b0-b1|` from n=2; the ratio is half-Cauchy, P=0.452. ⚠ The disconfirming evidence sat in brokkr's own sentence, and he named *why*: the claim was his and flattering. → `persistent-memory.d/2026-09-05-floor-claim-n2-retraction.md`