Record PP-5245 as the MinIO mirror's retirement ticket

[dbernstein]

Description

Names PP-5245 as the retirement ticket for the MinIO mirror, in the three places that previously
said it should be retired without saying where to find the ticket:

• images/minio/Dockerfile — the "bridge, not a destination" note
• .github/workflows/build-minio-mirror.yml — the header
• README.md — a new ### Retirement section

Two smaller cleanups while in there:

• The README's retirement section now carries the 5,000-download deletion threshold next to the
  gh api -X DELETE command, so the cost of waiting is visible right where someone would go to act.
  Previously the threshold was a trailing sentence and the command lived only in a PR description.
• The workflow's "one-time manual step: flip the package to public" note read as a pending TODO. It
  has been done, so it now records what was done and notes it would need doing again if the package
  were ever recreated — GHCR creates packages private and the workflow cannot change that.

Motivation and Context

The mirror exists because MinIO withdrew anonymous public access to its server image from both
Docker Hub and quay.io (#2). It is deliberately a stopgap, and
images/minio/Dockerfile tells readers "do not add features to it" — but it then pointed at a
"retirement ticket" that had no identifier, so there was no way to follow the instruction to its
conclusion.

That gap matters more than a missing cross-reference normally would. Retiring this gets strictly
harder with time: GitHub does not allow self-service deletion of a public package once any version
passes 5,000 downloads, after which it takes a Support request. With pull=True on every
tox-docker build, ephemeral CI runners and three repos pulling, an untracked mirror is one that
quietly becomes permanent.

Also: the mirror's entrypoint difference from upstream

A second commit records a behavioural difference that had already caused a real breakage. The
upstream image set ENTRYPOINT to a docker-entrypoint.sh that supplied the minio binary, so
docker run <image> server /data worked. This mirror ships no entrypoint, so that same invocation
fails with exec: "server": executable file not found in $PATH and the container never leaves
Created.

The three CI Dockerfiles all set their own command, so none of them hit this — which is why it went
unnoticed. But virtual-library-card's README documented exactly that invocation for local
development, and it broke silently (fixed in ThePalaceProject/virtual-library-card#1016). The
Dockerfile now says so next to its CMD, so the next person invoking the image directly finds it
before debugging a container that refuses to start.

How Has This Been Tested?

The Dockerfile change is comment-only — no instruction changes — so the image contents are
unchanged: the same release binaries pinned by sha256 and the same UBI base pinned by digest.

Note that merging this does re-trigger the publish workflow, because both changed files are in
its paths: filter. That is expected and harmless; the workflow's PR run on this branch builds both
architectures and verifies every pinned checksum without pushing, which is the check that the
Dockerfile is still valid. The published manifest digest may change even though the contents do not,
since buildx attaches fresh provenance to each build — consumers pin the tag, not the digest, so
nothing downstream is affected.

The entrypoint behaviour documented in the second commit was verified against the published image:
docker run <mirror> server /data --console-address ":9001" fails as described and leaves the
container in Created, while docker run <mirror> minio server /data --console-address ":9001"
comes up healthy in ~2s, with mc and the console both working inside it.

🤖 Generated with Claude Code