Pin run container images to immutable tags — and build the pipeline that publishes them

[debuggingfuture]

Every run that pins a container image pins a mutable :latest tag:

runs/ci-triage-pr.ts:130    registry.cloudflare.com/fractalbox/flare-dispatch-review:latest
runs/finops-audit.ts:122    …/flare-dispatch-review:latest
runs/org-spec-audit.ts:233  …/flare-dispatch-review:latest
runs/pr-review.ts:243       …/flare-dispatch-review:latest
runs/release-notes.ts:295   …/flare-dispatch-review:latest
runs/spec-drift-pr.ts:109   …/flare-dispatch-review:latest
runs/triage-prs.ts:151      …/flare-dispatch-review:latest
runs/playwright-e2e.ts:63   …/flare-dispatch-playwright:latest
runs/self-heal-pr.ts:90     …/flare-dispatch-agent:latest

A mutable tag means production behavior changes without a source change: two dispatches of the same run at the same commit can execute different code, a rollback has nothing to roll back to, and a dispatch cannot be audited against what actually ran.

There is no immutable tag to point at yet — the repo has no Dockerfile and no image build/publish workflow (.github/workflows/ is deploy.yml + docs.yml), so the images are built and pushed out of band. The pipeline has to exist before the references can be pinned.

Steps:

1. Add an image build + publish workflow that tags by digest (and a semver/commit tag) on release.
2. Resolve the pinned reference from one place rather than a string literal per run, so a bump is one edit and not nine.
3. Replace the :latest references with the immutable tag or @sha256: digest.

Raised as a warning on #93 against runs/triage-prs.ts:151. Deferred there because it is repo-wide convention, not something that PR introduced, and pinning one run to a versioned tag that nothing publishes would point it at an image that does not exist.