R-385 record: v0.221.1 gets its own CHANGELOG heading

0.221.1 was built, baked and vouched on 2026-08-23 with no entry of its own.
The prune-ordering fix (commit 810b18a) was written inside the v0.221.0 entry,
so the newest heading in the record named 0.221.0 while the fleet ran 0.221.1.

The image was never in question - the record was. The reasoning is MOVED, not
rewritten: the paragraph is verbatim from the v0.221.0 entry, which no longer
claims it. The new entry also names the pinning test and its red-proof.

Pushed alone and before anything else this session, so the record is correct
even if the rest of the session does not land.

CHANGELOG.md

@@ -1,3 +1,28 @@
+## v0.221.1 — the undo-copy prune stopped running because another fix made its guard reachable (2026-08-23, R-361 follow-on)
+**MinAgent: 0.129.0** (unchanged — no new agent coupling)
+
+**This version was BUILT, BAKED and VOUCHED on 2026-08-23 and had no CHANGELOG entry of its own until
+now (R-385).** Its fix was written inside the v0.221.0 entry instead, so the record named a version
+that was not the one running. Nothing is wrong with the image; the record was. The reasoning below is
+moved here verbatim from that entry — it is not new text, and v0.221.0 no longer claims it.
+
+**One change made another unreachable, and only the live box showed it.** Excluding the undo copies
+from `db_dumps` made that list STABLE across restores — which is correct — and that made
+`CaptureRecoveryUnit`'s already-current early return start firing where it never had. The undo-copy
+prune sat *after* that return, so the cap silently stopped applying: **four copies on disk against a
+cap of three, counted on `demo-hp` minutes after the change.** The prune now runs above the check,
+where it belongs — it is housekeeping on the dump directory and has nothing to do with whether the
+manifest needs rewriting.
+
+**Why it is safe above the check:** pruning cannot disturb `dbDumps`, which after v0.221.0 no longer
+contains those names.
+
+**Test:** `TestR361_UndoCapHoldsWhenTheUnitIsAlreadyCurrent`
+(`internal/backup/r361_canonical_dump_test.go:245`). **Red-proof:** move the prune call back below the
+already-current early return — the cap fails at 5 copies against a cap of 3.
+
+**Shipped as commit `810b18a`.**
+
 ## v0.221.0 — taking the undo copy destroyed the app's own database backup (2026-08-22, R-361)
 **MinAgent: 0.129.0** (unchanged — no new agent coupling)
 
@@ -31,14 +56,6 @@ consumer exists. Excluding them also makes that compare stable, since the copies
 every restore and prune. **The files are neither deleted nor hidden** — their visibility is a
 recorded design decision and it stands.
 
-**One change made another unreachable, and only the live box showed it.** Excluding the undo copies
-from `db_dumps` made that list STABLE across restores — which is correct — and that made
-`CaptureRecoveryUnit`'s already-current early return start firing where it never had. The undo-copy
-prune sat *after* that return, so the cap silently stopped applying: **four copies on disk against a
-cap of three, counted on `demo-hp` minutes after the change.** The prune now runs above the check,
-where it belongs — it is housekeeping on the dump directory and has nothing to do with whether the
-manifest needs rewriting.
-
 **Tests:** `internal/backup/r361_canonical_dump_test.go`, additions to
 `internal/appbackup/r381_undo_naming_test.go`, `cmd/controller/r361_classifier_control_test.go`.
 Test count 1485 → 1493.