ci(promote-base-latest): re-point base-latest by digest, not need_build

The gate keyed off need_build=='true', assuming need_build==false meant
base-latest was already current. A dry-run dispatch (promote_latest=false)
that pre-builds base-<hash> falsifies that: the later tag run sees
need_build==false and skipped promotion, leaving base-latest one base
behind (observed 2026-06-27, v1.2.3 dry-run-first release).

Gate now runs on every tag release / promote dispatch; the no-op
optimization moved into the step as a crane digest compare so it re-tags
only when base-latest actually differs from the released base-<hash>.
Workflow-only change; base hash unaffected (no base rebuild).

CHANGELOG.md

@@ -13,6 +13,23 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
 
 ## Unreleased
 
+### Fixed (CI)
+
+- **`promote-base-latest` now re-points `base-latest` reliably after a
+  dry-run-first release.** The job's gate previously required
+  `need_build == 'true'`, on the assumption that `need_build == false`
+  implied `base-latest` was already current. That assumption breaks when a
+  `workflow_dispatch` dry-run (`promote_latest=false`) pre-builds and pushes
+  `base-<hash>` first: the subsequent tag run then sees `need_build == false`
+  (probe hit) and **skipped** promotion, leaving `base-latest` pointing at the
+  *previous* base. (Observed 2026-06-27 releasing v1.2.3 via dry-run-then-tag
+  — `base-latest` ended up one base behind, lacking the mempalace self-heal.)
+  Now the gate runs on every tag release (or `promote_latest=true` dispatch),
+  and the no-op optimization moved **into** the step as a `crane digest`
+  compare: it re-tags only when `base-latest` actually differs from the
+  released `base-<hash>`, so genuine cache-hit releases stay a no-op while
+  stale aliases get corrected. No image-content change; base hash unaffected.
+
 ---
 
 ## v1.2.3 — 2026-06-27