Publish deploy images to GHCR instead of building on the host

[simonvanlierde]

Now

just <env>-build builds every image on the deploy host, tags it <env>-local plus <env>-<sha>, and just <env>-rollback retags from those. prune_sha_tags keeps the newest five. This is a stand-in for a registry: it costs the VPS 3-4 GiB and minutes per release, ships an image Trivy never scanned, and needs custom retention.

Proposed

• CI job on main and release tags builds the deploy images once and pushes them to ghcr.io/cmlplatform/relab-<service>:<sha> and :<version>.
• compose.deploy.yaml references image: ghcr.io/cmlplatform/relab-<service>:${IMAGE_TAG:?}; IMAGE_TAG lives in the host .env.
• Deploy: just <env>-up YES migrations pulls. Rollback: set an older IMAGE_TAG, same command, plus the existing alembic downgrade gate (scripts.maintenance.downgrade_safety).
• Retention: GHCR package retention policy; delete prune_sha_tags, stack_images, the sha tagging in build, and the image checks in rollback.
• Local build stays only for the dev, CI and smoke overlays.

Decide first

• Does staging track main automatically (deploy on every push) or also deploy by explicit tag?
• Public images (no host credentials) or private with a read-only token in secrets/<env>/?

Keep

The .env ENVIRONMENT guard, the downgrade safety check, and the stop api → downgrade → up order in rollback are independent of where images come from.