ci(release): publish the operator image + chart, and a promotion manifest

[jiejingzhangamd]

Based on #90 — retargeted at feature/weilei/build_operator, so this diff
is only the workflow. #90 makes the manager a component tag of the shared repo
(rocm/infera:operator-<version>) rather than its own -operator-manager
repository; this follows that convention.

Two things a release did not produce, both left to a human afterwards.

1. The operator image and its Helm chart

The build already existed — make docker-build / docker-push / helm-push in
deploy/operator — but nothing ran it on a tag. So helm install pulled
whatever manager image happened to be committed in values.yaml, which is how a
chart quietly installs a months-old manager.

The new job pins, before packaging:

	from
Chart.yaml version / appVersion	the tag, without the leading v
values.yaml image.repository	<IMAGE_REPO> (the shared repo)
values.yaml image.tag	operator-<tag>, with the v

so a plain helm install gets the manager this run built. The v asymmetry is
not a slip: Helm requires SemVer and helm package rejects v0.2.3.

It runs on a GitHub-hosted runner — the operator Dockerfile is a distroless
CGO_ENABLED=0 Go build, needing neither a GPU nor the SLURM dispatch the
engine images go through. Deliberately not gated on build or overlay:
the operator ships no engine code, so waiting on a GPU queue would only delay a
chart nobody was blocked on.

Pushing goes through the existing Makefile targets rather than open-coding
helm here, so there is one definition of how a chart is built and named.

2. promotion-<id>.json

Engine images publish to the private staging repo and are promoted to the public
one after review. That promotion is a separate, human-gated process — this job
does not perform it. It writes down, for this exact release, which source
maps to which destination:

[
  {"source": "inferaimage/infera:sglang-v0.2.3",  "destination": "rocm/infera:sglang-v0.2.3"},
  {"source": "inferaimage/infera:vllm-v0.2.3",    "destination": "rocm/infera:vllm-v0.2.3"},
  ...
]

Generated from prepare's component list, so a partial dispatch produces a
partial manifest rather than naming images that were never built — which is
the failure mode of writing the list by hand afterwards. Uploaded as a workflow
artifact, and on a tag also attached to the GitHub Release.

Destination defaults to rocm/infera, overridable with a PROMOTE_TO_REPO
Actions variable.

Also: one id, not three

The image-id computation was open-coded identically in build and overlay.
Harmless while they agree — but the overlay harvests the engine images by
tag, so an id that diverged between jobs would silently harvest the wrong
ones. It is now computed once in prepare and passed down.

Verified locally

• The manifest generator reproduces the expected JSON exactly for a v0.2.3
  tag (6 entries: 5 engines + overlay).
• The chart-pinning steps produce version: 0.2.3, appVersion: "0.2.3",
  image: docker.io/inferaimage/infera-operator-manager:v0.2.3, render through
  helm template, and package to infera-operator-0.2.3.tgz.
• Workflow YAML parses.

Not verified: the pushes themselves. Neither the manager image, the chart,
nor the release upload has run — that needs a real tag with credentials. The
first release after this merges is the real test, and the failure mode is loud
(a failed job), not silent.

The operator is now in the manifest

My earlier open question — whether the manager belonged in the promotion list —
is settled by #90. Making it a component tag of the same repo means it promotes
exactly like the engines, so it is included:

{"source": "inferaimage/infera:operator-v0.2.3", "destination": "rocm/infera:operator-v0.2.3"}

7 entries: 5 engines + overlay + operator.

Still open: does a relayed image stay the same image?

The manifest maps tag to tag, with source derived from wherever the build
pushed. That is exact for a direct copy. It is not exact if the images pass
through an intermediate registry, for two separate reasons:

1. source may not be where the promoter pulls from. Easy to fix — make the
   source repo configurable independently of IMAGE_REPO.
2. A tag is not an identity. Any hop can put different bytes behind the same
   tag; a re-tag or a re-push through a mirror produces a rocm/infera:... that
   is not what was built and reviewed, and the manifest cannot tell. This is
   not hypothetical for us: 13 recipes pin the overlay by @sha256: precisely
   because digests are immutable and tags are not.

The fix, if there is a relay, is to carry the digest:

{"source": "...", "source_digest": "sha256:…", "destination": "..."}

which turns the manifest from a copy instruction into something verifiable after
the fact. The digest is free — docker push already prints it.

Not doing this yet: it depends on whether there is a relay and where, and on
whether the promotion tool tolerates an extra field or validates a strict
schema. Worth confirming before adding.