feat(runner-image): add Xcode 26.0.1 runner profile

What

Adds Xcode 26.0.1 (the latest 26.0 patch) as an additional, non-default macOS runner profile across the fleet, mirroring how 26.3 was added in tuist#11197.

profiles.json becomes ["26.5", "26.4.1", "26.3", "26.0.1"] — 26.0.1 is appended last, so 26.5 stays the default profile. Because the first (default) entry is unchanged, the xcresult-processor XCODE_VERSION does not need bumping.

Why

This is step 1 of making the CLI release build faster. Investigation of the failed canary (run 28110092034) showed the Bundle CLI step takes ~23 min — essentially the whole job — and runs on the GitHub-hosted macos-26 runner, the only macOS workflow not on the self-hosted tuist-macos fleet. Moving it to tuist-macos gives faster hardware and a co-located Xcode compilation cache (CAS), instead of cache round-trips timing out over the public internet (the failed run logged 147 CAS error: deadlineExceeded).

The blocker: the tuist-macos fleet uses a per-Xcode image model (one Xcode per runner, chosen by label, no xcode-select). The release pins Xcode 26.0 (.xcode-version-releases), but 26.0 is no longer in the active fleet (active: 26.5 / 26.4.1 / 26.3). This PR brings a 26.0.x profile back so the relocation can keep building the release on a 26.0 toolchain. The runner-relocation itself is a follow-up PR.

Changes

• infra/runner-image/profiles.json — append "26.0.1" (source of truth for the build matrix + fleet).
• Helm catalog: values.yaml + values-managed-common.yaml xcodeVersions, and per-env xcodeOverrides (values-managed-{canary,staging,production}.yaml). All cold (minWarmPoolFloor: 0); maxReplicas matches each env (1 canary/staging, 9 production).
• Server runner catalog: server/config/config.exs (+ catalog_test.exs assertions for the 26-0-1 pool name and JSON parsing).
• Docs: infra/macos-xcode-image/AGENTS.md (commands + profile-set list; the table already had the 26.0.1 row) and infra/runner-image/AGENTS.md (profiles example).

Prerequisite — ✅ done, safe to merge

The Layer 1 base images had to exist in GHCR before merge, otherwise release-runner-image’s Layer 2 build would clone a missing macos-tahoe-xcode:26-0-1 base and fail. Both are now published and verified (2026-06-26):

1. ✅ ghcr.io/tuist/xcode-xips:26.0.1 — Layer 0 xip mirror, via mise run xcode-mirror:upload 26.0.1 (maintainer Mac, Apple ID 2FA).
2. ✅ ghcr.io/tuist/macos-tahoe-xcode:26-0-1 — Layer 1 base, built by macos-xcode-image.yml run 28222909386 (success).

On merge, the runner-image component release builds Layer 2 tuist-runner:macos-26-0-1-<semver> against that base and the chart renders the cold 26.0.1 pool (…-runner-pool-macos-26-0-1; floor 0, max 1 canary/staging, 9 production).

After merge (for the follow-up runner relocation)

The 26.0.1 pool is rendered by this PR’s config, but dispatch resolves (account, runs-on label) → Profile → pool, and Profiles are per-account DB rows (server/lib/tuist/runners/profiles.ex), not config. So before the follow-up can point the CLI release at runs-on: tuist-macos-26-0-1, a matching Profile must be created on the Tuist org account — the same way the tuist-macos-26-3 label used by backward-compat acceptance was set up. Without it, dispatch returns RunnerNotFound.

Validation

• infra/runner-image/profiles.json is valid JSON; the 5 Helm files follow the exact 26.3 block shape.
• server/test/tuist/runners/catalog_test.exs extended to assert 26.0.1 → <prefix>-26-0-1 and 4-entry JSON parsing (local full run blocked by an unrelated worktree dep-lock issue; CI runs it).
• Layer 1 / Layer 0 GHCR tags confirmed present (see prerequisite section).

Note on scope

Commit is scoped runner-image (per infra/runner-image/AGENTS.md) since its component release is what builds the new profile’s image; the server/helm changes still deploy via the path-triggered server-production-deployment pipeline.

🤖 Generated with Claude Code

No GitHub comments yet.