fix(server): run deploy dispatch on ubuntu-latest for the gh CLI

What

The trigger-deploy job in release.yml (the job that dispatches the production deployment after a fleet/runtime image release) now runs on ubuntu-latest instead of the self-hosted tuist-linux runner, drops its unnecessary actions/checkout, and targets the repo explicitly with --repo.

Why

trigger-deploy is the linchpin of the tag-resolved release pipeline merged in #11160: when a fleet image (runner-image / linux-runner / runners-controller / capi-scaleway / xcresult-processor-image / kura) releases, this job dispatches server-production-deployment.yml so the new image ships with the server in one pass. The push-triggered deploy’s gate job deliberately defers whenever a fleet image is releasing, handing ownership of that deploy to trigger-deploy.

The job called gh workflow run but ran on tuist-linux, our self-hosted microVM image, which has no gh CLI on PATH. It failed immediately:

gh: command not found
##[error]Process completed with exit code 127.

Root cause

The dispatch is the one place in the release pipeline that needs the GitHub CLI. The sibling tag-infra-releases job works on tuist-linux because it only uses plain git to push tags. tuist-linux images do not ship gh; GitHub-hosted ubuntu-latest runners do.

Impact (observed on the first post-merge cycle)

• The merge commit was a fleet-image cycle (xcresult-processor-image + kura). Its push-triggered Server Production Deployment correctly deferred (gate → all cascade jobs skipped), expecting trigger-deploy to dispatch.
• trigger-deploy then failed on gh: command not found, so no production deploy was dispatched. Images were built and tagged (xcresult-processor-image@0.14.0, new kura@/server@ tags landed correctly), but production never rolled forward to them.
• Because subsequent commits include a fix(kura) (792d24d), kura-should-release stays true for every following push, so each push keeps deferring to the (broken) trigger-deploy — production is stuck until this lands.

Fix

ubuntu-latest has gh preinstalled. The dispatch needs no working tree (the SHA and commit subject come from the event context), so the checkout is removed and the repo is passed via --repo "${{ github.repository }}".

Validation

• Confirmed the failure in Release run 27211019718 (trigger-deploy → exit 127, gh: command not found).
• Confirmed the rest of the redesign works: builds, tag-infra-releases (tags pushed), the push-gate deferral, Publish releases, and no [Release] commit on main.
• YAML parses; actionlint reports only the pre-existing tuist-linux custom-label and uploaded/SC2086 warnings, none in the changed block.

Note (separate, pre-existing)

The pre-merge production deploys (e.g. 8073b7a) were already failing at the canary leg (canary / Platform chart, canary / Observability chart) — a distinct issue unrelated to this dispatch bug. Worth a separate look once this unblocks the dispatch path.

🤖 Generated with Claude Code