ci: never prune a manifest a tag still references

[eetu]

ghcr.io/eetu/dice:1 is currently unpullable on every platform. The prune added in #56 deleted it.

What happened

The step assumed untagged means build leftover:

Untagged versions are the intermediate manifests each multi-arch build leaves behind; the tagged ones (1.0.8, 1.0, 1, latest, main) are never candidates.

For a multi-arch image that isn't true. The tag goes on the index; the index's per-architecture child manifests are separate, untagged package versions referenced only by digest. They are the image. Delete them and the tag still resolves to an index, but every platform it points at is gone.

With 2 children per build and KEEP: "5", the window covered barely two builds, so children of still-tagged indexes fell out and were deleted. Current state:

ghcr.io/eetu/dice:1        BROKEN: 2/2 children MISSING   ← index intact, both children gone

continue-on-error: true meant none of it ever showed up as a red build.

Why it matters beyond a warning

The invinite-tech host has been failing podman-auto-update nightly since 00:10 today:

Error: checking image updates for container ...: fetching target platform image
selected from image index: reading manifest sha256:2b5b2d19... in ghcr.io/eetu/dice:
manifest unknown

The container is still up only because the image is already in local storage. A server recreate, an image prune, or any forced re-pull would have left dice unable to start — silently, since the app looks healthy right now.

The fix

Collect every digest referenced by a tagged index and exclude those, then keep the 5 newest of what genuinely is unreferenced. The registry read uses docker buildx imagetools inspect, already set up and logged in earlier in the job, so no extra token handling.

It also fails closed: if tagged multi-arch images exist but no referenced digests could be read, it refuses to prune rather than treating a blank answer as "nothing is referenced" — the same class of mistake that caused this.

Verified against the live package

Both logics delete nothing today (the damage is done, only 15 versions remain), so I re-ran with the window tightened to KEEP=0 to simulate it having slid:

OLD logic candidates: 5
  ...REFERENCED by a live tag (deleting these breaks the tag):
     BREAKS: sha256:64c39d6872bb0b6028c     ← child of :main
     BREAKS: sha256:5dedf9788c7ad3fd9b3     ← child of :main

NEW logic candidates: 3
  ...referenced (must be none):
     (nothing above = safe)

The keep-set resolved 20 referenced digests across 13 tags.

This does not yet fix :1

Merging this only rebuilds :main — the semver tags (1, 1.0, latest) are type=semver, so they publish only on a v* tag. Restoring :1 needs a release. I'll follow up with just release patch → v1.0.9 once this is in, which republishes 1.0.9/1.0/1/latest with the fixed prune already live. The CHANGELOG entry here covers it.

I'd also suggest a workflow_dispatch trigger as a separate change, so a future "republish this tag" doesn't need a version bump — happy to add it.