fix(base-images): include the snapshot time in the immutable tag

The snapshot timestamp, not just its date, determines the published
digests; a same-commit dispatch with an intra-day snapshot time could
otherwise overwrite the tag and orphan the earlier digests.

Author: myftija

.github/workflows/base-images.yml

@@ -91,7 +91,7 @@ jobs:
             echo "build_packages=$BUILD_PACKAGES"
             echo "suite=$SUITE"
             echo "snapshot=$SNAPSHOT"
-            echo "publish_id=${SNAPSHOT:0:8}-${SHA:0:7}"
+            echo "publish_id=${SNAPSHOT:0:8}-${SNAPSHOT:9:6}-${SHA:0:7}"
             echo "source_date_epoch=$EPOCH"
             echo "push=$PUSH"
           } >> "$GITHUB_OUTPUT"

base-images/README.md

@@ -15,7 +15,7 @@ images derived from these behave like their upstream bases.
 
 Tags are mutable and rebuilt in place on demand; each rebuild picks up Debian
 security updates published up to its snapshot date. Every publish also pushes
-an immutable per-publish tag (snapshot date plus commit, e.g. `22-bookworm-20260812-45444a7`) so previously
+an immutable per-publish tag (snapshot timestamp plus commit, e.g. `22-bookworm-20260812-000000-45444a7`) so previously
 published digests stay tag-referenced; never delete these, since shipped CLI
 releases pin their digests. The
 runtime itself (the node or bun binaries from the upstream base) only moves