feat: add release candidate tagging workflow

[randy-concepcion]

What's New

• Adds .github/workflows/tag-release-candidate.yml, a workflow_dispatch workflow that tags an existing main-build image in GAR as a release candidate (vX.Y.Z-rc.N)
• Tags the existing digest directly (no pull, no rebuild) via gcloud artifacts docker tags add
• Inputs: a full commit SHA and an RC number
• Validates the commit is on main, reads the version from pyproject.toml, and derives the RC tag
• Safe to re-run: re-tagging the same digest is a no-op, and it refuses to move an existing RC tag to a different digest. Fails closed if the source image is missing or the registry lookup errors.
• Keyless auth via the existing artifact-writer Workload Identity setup, no new secrets or permissions

Context

This PR is part of AIPLAT-911 (per-environment image tiers). It establishes the stage tier for MLPA: dev runs latest, stage will pin to an RC tag, and prod stays on stable semver.

The workflow promotes a selected main-build image to vX.Y.Z-rc.N by adding a tag to the existing digest in GAR. It does not rebuild, pull, or push any image. A separate follow-up PR will add a stable promotion workflow triggered on GitHub release.

Testing

Not yet run. A workflow_dispatch workflow only appears in the Actions "Run workflow" UI after it lands on the default branch, so it can't be triggered from the PR branch. Will validate post-merge by promoting a known main build and confirming the RC tag lands on the expected digest.

How to use

From the Actions tab, select "Tag Release Candidate in GAR", click "Run workflow" on main, and provide:

• The full commit SHA of a main-branch build
• The RC number (1, 2, 3, ...)

The workflow produces a job summary table with the commit, source tag, version, RC tag, and digest.

Related

• AIPLAT-911