fix(ci): the v-prefixed image alias must be {{raw}}, not v{{version}} (+ VERSION 0.9.5-rc2)

[obasilakis]

Refs #2281 (DigitalOcean Marketplace packer bundle — this unblocks its build)
Refs #2280 (prebuilt images + pull-only hosted compose — the workflow this fixes)
Refs #2332 (Epic: one-click hosted install)

Closes nothing: each stays open on its own acceptance criteria.

---

Blocks the DigitalOcean snapshot. Found by cutting v0.9.5-rc1 — same family as #2499, one line over.

Two commits, deliberately batched: the workflow fix, and the VERSION bump to 0.9.5-rc2. Both are prerequisites for the same rc2 cut and need the same reviewer; dev is protected, so splitting them would buy a second full review cycle for a one-line file. The playbook already batches release-prep writes this way (Step 4 + Step 6a share one branch).

What happened

All five packages published 0.9.5-rc1 and sha-0f4d54d. No v0.9.5-rc1. Verified against the live registry:

trinity-backend        0.9.5-rc1, sha-0f4d54d
trinity-frontend       0.9.5-rc1, sha-0f4d54d
trinity-scheduler      0.9.5-rc1, sha-0f4d54d
trinity-mcp-server     0.9.5-rc1, sha-0f4d54d
trinity-agent-base     0.9.5-rc1, sha-0f4d54d

v{{version}} is a component pattern, so metadata-action drops it for a pre-release under the same documented rule that correctly drops {{major}}.{{minor}}:

"Pre-release (rc, beta, alpha) will only extend {{version}} (or {{raw}} if specified) as tag"

#2499 reasoned about that rule for {{major}}.{{minor}} and didn't carry it one line up. {{raw}} is the documented exception, and it keeps the v (v1.2.3 → v1.2.3).

Why it isn't cosmetic

It broke the marketplace build — the one thing the RC was cut for. packer/digitalocean/scripts/01-provision.sh feeds a single TRINITY_IMAGE_TAG to two consumers that need different strings the moment those strings diverge:

line 86:   git clone --depth 1 --branch "${TRINITY_IMAGE_TAG}"    # wants the GIT tag → v0.9.5-rc1
line 93:   docker pull ghcr.io/abilityai/trinity-${img}:${TAG}    # wants the IMAGE tag → 0.9.5-rc1
line 101:  docker pull ghcr.io/abilityai/trinity-agent-base:${TAG}

They're the same string only while this alias exists. Without it there is no value of image_tag that builds the snapshot: v0.9.5-rc1 fails both docker pulls, 0.9.5-rc1 fails the git clone.

#2280's comment predicted the shape of this exactly — "makes the release name and the image tag the same string, which is what anyone reading the releases page will type" — it just didn't account for the pre-release rule removing the alias on precisely the tags where nobody had looked yet.

It also silently degrades real releases' operator ergonomics: every doc and start.sh's own pin warning say TRINITY_IMAGE_TAG=v0.9.0, and start.sh:529 blames the operator's spelling when that 404s.

The change

- type=semver,pattern=v{{version}},enable=${{ github.event_name == 'push' }}
+ type=semver,pattern={{raw}},enable=${{ github.event_name == 'push' }}

v0.9.5 → v0.9.5 (identical for real releases) · v0.9.5-rc1 → v0.9.5-rc1 (currently nothing).

{{version}} and {{major}}.{{minor}} are untouched — the first is what a prerelease extends, the second is correctly withheld from one.

Verification

• tests/unit/test_2471_publish_images_prerelease_latest.py extended to 5 tests, all passing. Verified to catch the bug: reverting the one-line change fails 2 of them.
• The suite now pins the asymmetry in both directions — {{raw}} present, v{{version}} absent, and no hyphen guard on any semver pattern (an RC must stay pullable by its exact tag).
• yaml.safe_load on the workflow — parses.
• Behaviour confirmed against docker/metadata-action's documented pre-release rule, and against the live GHCR tag list above.

After this lands

v0.9.5-rc1 is not re-cut — an RC tag is immutable by the playbook's own rule, since its images may already sit in a vendor queue. With VERSION already at 0.9.5-rc2 from this PR, the next step is just the tag push, then packer build -var image_tag=v0.9.5-rc2 — the first time that command can succeed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K9bL6DZ8QVyrSvPybp5ZuK

[webmixgamer]

Reviewed with /review, /cso --diff and /validate-pr: no critical findings.

• Tests verified locally: 5 pass on the branch, and restoring the origin/dev workflow line fails exactly the 2 alias tests.
• Bug reproduced against GHCR with an anonymous manifest inspect: trinity-backend:0.9.5-rc1 present, :v0.9.5-rc1 absent.
• metadata-action rule confirmed in the vendor README ({{raw}} keeps the v on a pre-release); the four docker/* SHA pins resolve to the versions their comments claim.

One ask before merge: add Refs #2281 to the body, matching #2499 and #2471, so the PR is traceable to the listing it unblocks. A flow-doc paragraph for the pre-release tag set (hosted-install.md still describes release tags only) follows in a separate docs PR.