ci: pin xcodes 2.0.3 to fix iOS runtime installs

[RoyalPineapple]

Problem

All three iOS jobs (15.4 / 16.2 / 17.2) fail in ~9s at the Install iOS <sdk> step, on main and every open PR, since ~2026-07-07:

Error: dataCorrupted(... codingPath: [downloadables, Index 393, authentication],
"Cannot initialize Authentication from invalid String value none")

Apple added an authentication: "none" value to its runtime-downloadables JSON that the runner's preinstalled xcodes 2.0.2 can't decode. xcodes 2.0.3 (released 2026-07-08) fixes the decode. Pure infra; no code change involved.

Fix

In the failing step only: upgrade xcodes via brew when the preinstalled copy is older than 2.0.3.

xcodes="$(brew --prefix)/bin/xcodes"
required="2.0.3"
installed="$("$xcodes" version)"
lesser="$(printf '%s\n%s\n' "$required" "$installed" | sort --version-sort | head -1)"
if [ "$lesser" != "$required" ]; then
  brew update --quiet
  brew upgrade xcodes
fi
sudo "$xcodes" runtimes install "iOS ${{ matrix.sdk }}"

• Version-gated: version-sort the pair and upgrade only if the lesser one isn't required (i.e. the installed copy is older). Once GitHub rebuilds the image with xcodes ≥ 2.0.3, the brew block is a silent no-op and this fix self-retires.
• Note: the upgrade installs brew's latest xcodes, not pinned 2.0.3 (currently they're the same). 2.0.3 is only the minimum that decodes Apple's current list; Homebrew has no cheap way to install a pinned historical formula version, and the alternative (downloading the release artifact directly) was rejected as worse.
• brew update before upgrade: the image's formula index is frozen at image-build time (auto-update disabled), so brew upgrade alone considers the stale 2.0.2 "up-to-date" and does nothing.
• Explicit $(brew --prefix)/bin path: sudo's secure_path ignores the job PATH, so a bare sudo xcodes would still resolve the stale copy.
• This upgrades the same brew-managed xcodes the image already ships (toolset-15.json installs it via brew.common_packages), rather than adding a second install mechanism.

Why not a newer runner?

• macos-15 is the newest image that ships Xcode 16.4, which env.properties pins and the iOS 15.4/16.2/17.2 simulator matrix requires. macos-26 only ships Xcode 26.x, so switching runners would mean an Xcode migration, not a CI tweak.
• A newer image wouldn't have dodged this anyway: xcodes 2.0.3 was released the day before the breakage surfaced here, so every macOS image built before then — including macos-26, which installs xcodes via brew the same way — carries the broken version.

Verification

• Locally confirmed brew's xcodes 2.0.3 decodes Apple's current runtime list and lists iOS 15.4 / 16.2 / 17.2, and the version comparison handles 1.4.1 / 2.0.2 / 2.0.3 / 2.1.0 / 10.0.0 correctly.
• On this PR's CI: all three "Install iOS" steps pass and all three iOS jobs are green.

🤖 Generated with Claude Code

[johnnewman-square]

🤖 Non-blocking nit: the version check resolves xcodes via the job PATH, while the install below invokes $(brew --prefix)/bin/xcodes explicitly. On these images both resolve to the same brew-managed binary, but using "$(brew --prefix)/bin/xcodes" version here too would guarantee the version you check is the version you run.

[RoyalPineapple]

🤖 Addressed in df1de3a — the brew path is now resolved once into a variable and used for both the version check and the sudo invocation.