Resolve the latest release image to a published version

[CharlieTLe]

What this fixes

getLatestReleaseImage() in integration/util.go derives the "latest release" image
straight from the VERSION file, and .github/workflows/test-build-deploy.yml mirrors it
as docker pull quay.io/cortexproject/cortex:v$(cat testdata/VERSION).

That holds on master, where VERSION is the last GA and its image exists. It does not
hold on a release branch: VERSION is bumped to the version being prepared (e.g.
1.22.0-rc.0) long before anything publishes that tag, and the deploy job that would
publish it has needs: [build, test, lint, integration]. So the integration_query_fuzz
leg would try to pull an image that does not exist yet, and release-1.22 would be red
from the moment VERSION gains its -rc.0 suffix.

The same applies on the GA tag push, where VERSION is 1.22.0 with no suffix: the
v1.22.0 image is only pushed by deploy, which again runs after integration.

This mechanism landed in #7737 (2026-07-30), after v1.21.1, so it has never been through
a release.

The fix

VERSION names the version being prepared, so it cannot answer "what is published".
The registry can, so ask it — thanks @SungJin1212 for the suggestion.

A new Resolve Latest Release Image step lists the GA tags (^v\d+\.\d+\.\d+$) published
to quay.io, takes the highest one that does not exceed VERSION, and exports it as
CORTEX_LATEST_RELEASE_IMAGE for the preload and test steps. It runs only on the
integration_query_fuzz matrix leg, which is the only caller of getLatestReleaseImage().

Against a registry whose newest GA is v1.21.1:

VERSION	resolves to
1.21.1	v1.21.1	master's steady state
1.22.0-rc.0	v1.21.1	release branch preparing a minor
1.22.0	v1.21.1	the GA tag build
1.21.2-rc.0	v1.21.1	release branch preparing a patch
2.0.0-rc.0	v1.21.1	a major pre-release
1.19.0	v1.19.0	an older branch — note it does not jump forward
1.19.5-rc.0	v1.19.1	the newest published patch, not a guessed 1.19.4

The <= bound (rather than simply "the newest published GA tag") only changes the result
when a newer release already exists on quay than the branch being tested, e.g. preparing
1.21.2 on release-1.21 after v1.22.0 has shipped.

Setting the CORTEX_LATEST_RELEASE_IMAGE repository variable bypasses the lookup
entirely.

The bash mirror of the Go derivation is gone. latestReleaseVersion() stays in
integration/util.go as the offline fallback for local runs, where nothing sets the env
var and a network call is unwelcome; CI always resolves against the registry.

Verification

• The workflow step was extracted from the YAML and run under bash -e (what Actions
  actually uses — no pipefail, no nounset) against the live registry, producing every
  row in the table above, plus errors for a VERSION below everything published and for a
  malformed VERSION. The repository-variable override was exercised too.
• shellcheck is clean on the step. actionlint reports the same 13 pre-existing SC2086
  findings as master and no new ones.
• latestReleaseVersion() keeps its table test; getLatestReleaseImage() is tested end to
  end against a scratch checkout and for the env override.
• go vet passes with every integration build tag set.

[SungJin1212]

Thanks for catching this.

I think the issue with this PR is:
When we push the v1.22.0 tag, VERSION is 1.22.0, and this resolves to quay.io/cortexproject/cortex:v1.22.0. That image is published by deploy, and deploy needs integration to pass.

Can we ask the registry what is actually published? The registry is the only source of truth for "published".

1. Pick the highest published GA tag (^v\d+\.\d+\.\d+$) that is <= the base of VERSION
   ㄴ The <= bound only changes the result when a newer release already exists on quay than the branch being tested (e.g. preparing 1.21.2 on release-1.21 after v1.22.0 shipped).
2. Export it as CORTEX_LATEST_RELEASE_IMAGE