CI builds the runtime image but never publishes it — deploy-by-digest has no artifact to point at

Deploy-side context: mforce/cluckwork-deploy#6 (deploy manifest), go-live milestone. Follow-on to #266, which is closed — this is the one part of its fix that did not land, found while building the deploy manifest against the real image.

What is there today

.github/workflows/ci.yml has an image: job ("Image build + Trivy scan") that does the right build:

- name: Build runtime image
  run: docker build -f src/Cluckwork.Api/Dockerfile -t cluckwork-api:ci .

It builds the true multi-stage runtime image, proves --locked-mode is enforced (#315), and Trivy-scans HIGH/CRITICAL. That is real coverage and it works.

The gap

Nothing publishes that image. grep -rn "docker push|push: true|login-action|ghcr.io" .github/ returns no matches. cluckwork-api:ci lives in the runner's local daemon and dies with the runner.

#266's app-side fix listed "Identify the artifact by immutable commit SHA/digest." The build half shipped; the identify-and-publish half did not.

Why it blocks the deploy side

cluckwork-deploy#6 requires the image that passed CI is the image that deploys — deploy by digest, so a deploy cannot rebuild untested bytes. With no published artifact there is no digest to deploy, and the only options left on the host are:

rebuild from source at deploy time (defeats the requirement — different bytes than CI tested, and the Trivy scan result no longer describes what is running), or
build locally and push by hand (defeats CI gating entirely).

Neither is acceptable for go-live, so the deploy manifest cannot satisfy its acceptance criteria until an artifact survives CI.

Suggested shape (app-side; deploy repo has no say in your CI)

On main (and optionally tags), push the already-built image to ghcr.io/mforce/cluckwork, tagged with the commit SHA.
Publish only after build-and-test, web and the Trivy scan pass, so a red run cannot produce a deployable artifact.
Emit the resulting digest as a job output / step summary — the deploy side consumes ghcr.io/mforce/cluckwork@sha256:..., not a moving tag.
Needs permissions: packages: write on that job.

Package visibility (private vs public) and whatever pull credential the host uses are deploy-side concerns; I will wire those in cluckwork-deploy#6 once a digest exists to point at.

Not asking for

Any change to the deploy manifest, registry choice enforcement, or host wiring — those are mine. This issue is only "make the tested artifact survive CI with a stable digest".