fix(server): run deploy dispatch on tuist-linux now that gh is in the image

What

Moves release.yml’s trigger-deploy job back to the self-hosted tuist-linux runner (from the ubuntu-latest stop-gap in #11187), now that gh is baked into the Linux runner image (#11188). The dispatch keeps --repo and needs no checkout.

Why

#11187 moved trigger-deploy to ubuntu-latest only because the job calls gh workflow run and the runner image had no gh. #11188 fixed that root cause by baking gh into the image, so the dispatch can run on tuist-linux alongside the rest of the release jobs.

⚠️ Merge gate — do NOT merge until the gh image is live on the production fleet

trigger-deploy runs on a tuist-linux Pod, so it only works once those Pods are actually running the gh-bearing image. As of opening this PR the production fleet is still pinned to shapeRunnerImage=0.5.0 (the pre-gh image) — the deploy that would roll out 0.5.1 failed at Backward-Compatibility Acceptance before reaching production. Merging this before 0.5.1 is live would reintroduce gh: command not found on the next fleet-image cycle.

Merge only after:

1. A production deploy has pinned runnersFleetLinux.shapeRunnerImage=…:0.5.1 (or later), and
2. gh --version is confirmed on an actual tuist-linux runner Pod.

🤖 Generated with Claude Code