registry_prune.py sorted candidate tags by the manifest GET response's
Date header - which is just "now", the moment the prune script made
that request - not when the image was actually built. Every tag it
queries in the same prune run lands within the same second, so the
"sort by age" was effectively random. On run #56 this deleted the tag
this same CI run had just pushed (4efe848, digest 60114dea) seconds
after pushing it, and seconds before the gitops step committed a
deployment pointing at that now-deleted digest - the cluster then
sat in ImagePullBackOff since the referenced image no longer existed.
Now reads the real "created" timestamp from the image's config blob
(resolving through a manifest list/index if the tag is multi-platform),
and always protects the current run's own SHA from deletion regardless
of sort order, as defense in depth against any remaining timestamp edge
cases.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
