feat: pin custom images to a deploy version via IMAGE_TAG default

[chutch3]

Deploys now run a pinned version of each custom image instead of floating :latest.

How

Each custom-image compose line becomes:

image: ${REGISTRY:-ghcr.io}/${REGISTRY_NAMESPACE:-chutch3}/warden:${IMAGE_TAG:-3.20.0}

• Deploy (swarm, IMAGE_TAG unset) → pulls the pinned :3.20.0 default. The version lives literally in the file.
• Bumping a release → edit the literal default (:-3.20.0 → :-3.21.0) in the compose files and redeploy. Manual and deliberate, like the kenku pin.
• Build (CI build.yml, task build/publish) → run with IMAGE_TAG=latest, so the same image: line tags/pushes :latest. This decouples the build tag from the deploy pin — otherwise bake --push would clobber the released version and stop updating :latest.

Why a variable and not a bare :3.20.0

The custom images are both built and deployed from the one compose image: field (unlike kenku, which is only deployed). A bare literal would make builds push to the pinned tag. ${IMAGE_TAG:-<version>} keeps the version literal in the file while letting build tooling override to :latest with a single env var.

Also fixes a parsing bug it exposed

ci images parsed image names with rfind(':'), which grabbed the : inside ${IMAGE_TAG:-3.20.0} → warden:${IMAGE_TAG. Switched to the first colon after the last / (image names can't contain :). Added a regression test (red/green).

Notes

• Pairs with fix: promote images from :latest so unchanged images get the release version #90 (promote :latest → :version); together they guarantee every release reliably produces the :version tags these pins depend on. fix: promote images from :latest so unchanged images get the release version #90 should land first.
• All 8 images already have :3.20.0 (last release), so this pin is immediately deployable.
• ci tooling tests: 28 passing.

🤖 Generated with Claude Code