docs(changelog): measure promote-base-latest's conditional re-tag

Closes the open question from v1.9.2's release verification. crane copy DOES
bump Hub's last_updated when it runs (run 669: digests differed, copy ran
17:10:04->17:10:08, base-latest.last_updated moved to 17:10). The
identical-digest path stays unproven by construction -- the job prints
'base-latest already current; nothing to promote.' and never copies -- so a
freshness assertion on the alias is conditional on base-decide's need_build,
not a blanket upgrade. Operational rule lives in the ci-release-watcher skill
(skillset c8034af); the pipeline property is recorded here.

CHANGELOG.md

@@ -69,6 +69,38 @@ sizes are compressed; the config blob carries no uncompressed totals). Measuring
 them needs a real pull, so they remain unverified — a green check 8 says nothing
 about them, and the script says so where a reader will see it.
 
+**`promote-base-latest`'s conditional re-tag is now measured, which closes an
+open question from the v1.9.2 release verification.** The job compares digests
+and re-tags `base-latest` only if stale, and that short-circuit determines
+whether a release watcher may assert *freshness* on the alias or merely
+*existence*.
+
+Measured on run 669: the digests differed (`want sha256:8c452575…`,
+`have sha256:f34ad201…`), the job logged
+`Promoting base-latest -> …:base-b5f2d03baae2`, `crane copy` ran
+`17:10:04 → 17:10:08`, and Docker Hub's `base-latest.last_updated` moved to
+`17:10`. So **a `crane copy` that runs does bump Hub's timestamp** — a manifest
+re-tag is a tag write.
+
+The identical-digest case remains *unproven by construction*: when `base-latest`
+already resolves to the new `base-<hash>` the job prints
+`base-latest already current; nothing to promote.` and never copies, so the
+timestamp legitimately stays put. A freshness assertion would then report a
+correct release as stale. The rule is therefore conditional on
+`base-decide`'s `need_build` — strengthen it to fresh-required only when
+`Dockerfile.base`, `rootfs/` or a folded `*_REF` has moved, and leave it as an
+existence check for the variant-only and docs-only releases that cache-hit the
+base. Operational guidance lives with the tooling that consumes it
+(`ci-release-watcher` skill, skillset `c8034af`); recorded here because it is a
+property of *this* pipeline.
+
+Worth restating alongside it, because v1.9.2 proved it the useful way: tag
+freshness is not the authoritative evidence that a base rebuild baked what you
+expected. The `se.jordbo.pi-devbox.*-ref` labels are — readable straight from the
+registry with no `docker` or `crane` (token → manifest index → per-arch manifest
+→ config blob), and worth validating against the *previous* tag first, since a
+reader that cannot show the old SHA cannot prove the new one.
+
 ---
 
 ## v1.9.2 — 2026-09-14