v0.226.1: ship the CountsUnknown fix under a NEW tag, not a rebuilt 0.226.0

0.226.0 was already deployed to demo-hp by hand when the fallback defect was
found. Re-pushing a changed image under a tag that is already running somewhere
is the :latest hazard with extra steps -- two different images, one name, and no
way for a box to tell which it has. So the fix ships as a patch.

CHANGELOG.md

@@ -1,3 +1,18 @@
+## v0.226.1 — the unknown that the v0.226.0 fix drew as a zero (2026-08-30, R-353 follow-on)
+**MinAgent: 0.129.0** (unchanged)
+
+**A patch release rather than a rebuild of 0.226.0, deliberately.** 0.226.0 had already been deployed
+to `demo-hp` by hand when this was found, and re-pushing a changed image under a tag that is already
+running somewhere is the `:latest` hazard with extra steps — two different images, one name, and no
+way for a box to tell which it has.
+
+The defect and its fix are described in full under v0.226.0's *"One defect the fix itself introduced"*
+heading: `RestoreFromRecoveryUnit`'s no-unit fallback returned a ZERO `UnitRestoreResult`, which is
+Scenario B's shape, so it would have told a customer whose volumes had just been restored that their
+backup held only settings. `CountsUnknown` carries the unknown instead, and a fourth sentence states
+it. Pinned by `TestUnitRestoreOutcome_NoUnitFallbackSaysUnknownNotEmpty`; the A5 seam test corrected
+alongside it.
+
 ## v0.226.0 — four ways the restore screen could mislead a customer (2026-08-30, R-353/R-357/R-358/R-360)
 **MinAgent: 0.129.0** (unchanged — no new agent coupling)