`arm64/alpine321` (22,930 entries) and `arm64/alpine322` (24,696 entries)
advertise `Built: R <ver>; NA; ...`. uvr matches the stamp's platform triple
plus R minor to pick binary over source, so no client matches those slots and
both silently serve as source-only, which is the regression the stamp was added
to prevent. The tarballs themselves carry the correct triple; only the index is
wrong.
Re-running the normal index update does not fix it: `upload_package_index()`
reuses the slot's remote `PACKAGES.db` and cranlike's `update_db()` only
reparses files whose md5 changed. Dropping `PACKAGES.db` to force a full reparse
does work, but for an S3 repo cranlike reads each package's metadata from the
CRAN source mirror on GitHub, so a 25k-entry slot means 25k requests to
raw.githubusercontent.com and a real risk of being rate-limited part-way.
Only the `Built` column is wrong, so correct it in place: patch the column in
`PACKAGES.db`, put it back, and let `upload_package_index()` re-emit `PACKAGES*`
from it. `update_db()` always rewrites the index files even when nothing was
reparsed, so no tarball is re-read and nothing is fetched from GitHub.
Alpine 3.21 is EOL: the website advertises only 3.23/3.24 and
`process-updates.yaml` dropped it, so remove its two leftover matrix entries
from the archive pipeline rather than repairing that slot.
pat-s
72de7ae6d1