No container image has been published since 2026-08-26: the CI migration dropped the ghcr publish job, but README and deploy/k8s still pull ghcr.io/ktsu-dev/gitlfscache:latest #80

What's wrong

The design spec commits to publishing a container image after each release (docs/superpowers/specs/2026-08-18-gitlfscache-design.md L199 and L228):``

A container publish step is added after a successful release, gated on the release having produced a version

The plan header claims the same: "a multi-architecture container image publishing from CI". The original dotnet.yml did this in a container: job that ran dotnet publish GitLfsCache.Service/GitLfsCache.Service.csproj -t:PublishContainer -m:1 -p:ContainerRegistry=ghcr.io -p:ContainerImageTags="<version>;latest", gated on should_release.

Commit 6fcbc1b ("ci: adopt the unified dotnet workflow", 2026-08-26) replaced that workflow and deleted the container: job. Commit bb21398 then moved CI onto ktsu-dev/.github's ci-shared.yml. Neither the new ci.yml nor any workflow in ktsu-dev/.github mentions containers or ghcr.

What still exists:

• GitLfsCache.Service/GitLfsCache.Service.csproj still has the container properties: EnableSdkContainerSupport, chiseled base image, linux-x64;linux-arm64, ContainerRepository=ktsu-dev/gitlfscache.
• README.md L46 still documents docker pull ghcr.io/ktsu-dev/gitlfscache:latest.
• deploy/k8s/statefulset.yaml L28 still deploys image: ghcr.io/ktsu-dev/gitlfscache:latest.

Failure scenario

Anyone deploying with the documented image or the k8s base gets the image built from the last release before 2026-08-26. None of the fixes since then are in it: #30/#32, #45, #47/#61, #46/#60, #57/#68, #48/#67, and the rest. The release notes and NuGet version then disagree with what is actually running.

Suggested fix / acceptance criteria

• After a CI run that produced a release version, a multi-arch (linux-x64, linux-arm64) image tagged <version> and latest is pushed to ghcr.io/ktsu-dev/gitlfscache. Use GITHUB_TOKEN, with packages: write, which ci.yml already grants, and -m:1, as the old job did.
• Where it lives is a choice. It can be a follow-on job in this repo's ci.yml that runs after the shared ci job and reads its release output, or an opt-in input on ci-shared.yml so other service repositories can reuse it. If the shared pipeline doesn't expose the released version as an output yet, that is part of this work.
• A release publishes a new latest, and docker pull ghcr.io/ktsu-dev/gitlfscache:<version> works for that version.