Remove redundant setup-xcode step from macOS CI

[adarshsm]

Closes #3369.

The macOS composite action selected latest-stable Xcode through maxim-lobanov/setup-xcode@v1.6.0. Hydra never invokes the Xcode toolchain, so the step does nothing for the macOS jobs and keeps a third-party action on the Actions allowlist for no reason.

Verification

1. Nothing in the tree touches the toolchain. No reference to xcodebuild, xcrun, clang, DEVELOPER_DIR, CFLAGS, LDFLAGS or MACOSX_DEPLOYMENT_TARGET in any workflow, script, or Python file, and no ext_modules/Extension(...) anywhere — nothing compiles native code.

2. Nothing compiles at install time. On macOS arm64 with Python 3.14 (the newest version in the test_macos matrix, so the most likely to be missing wheels), every dependency resolved to a prebuilt wheel:

Using cached pyyaml-6.0.3-cp314-cp314-macosx_11_0_arm64.whl (173 kB)
Downloading omegaconf-2.4.0.dev15-py3-none-any.whl (246 kB)

The compiler is never invoked, so the selected Xcode version cannot matter.

3. The test suite passes without any Xcode selection. Ran the core tests on macOS 15 (arm64) with DEVELOPER_DIR unset, i.e. the plain runner default that applies once this step is gone:

2237 passed in 58.12s

That excludes tests/test_completion.py, which fails in my local shell for an unrelated reason (tests/scripts/test_bash_install_uninstall.sh: line 18: python: command not found — the conda env on CI provides python, my login shell only has python3). Nothing in those failures relates to Xcode.

Worth noting for reviewers: removing the step does not remove a compiler. setup-xcode only selects among the Xcode versions already on the runner image by setting DEVELOPER_DIR; without it the image default stays active, and Command Line Tools still provide clang. So even a future dependency that needs to build from source would still build.

The two callers of this action — the test_macos matrix in core_tests.yml and the macOS leg of release validation in prepare-release.yml — are unchanged, and both should be watched on this PR as the issue asks.

[adarshsm]

Heads-up on the red process check — it is not caused by this PR, and I think it is worth looking at on its own.

The Backlog Atlas job does its work correctly (it computed backlog: 3369 not started → community PR; link 3380 to 3369 and committed it), then fails trying to push:

remote: Permission to hydra-ecosystem/hydra.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/hydra-ecosystem/hydra/': The requested URL returned error: 403

GITHUB_TOKEN is read-only for pull_request runs from a fork, so the push to the backlog-atlas branch cannot succeed from a community PR no matter what the diff contains.

This looks like it will affect every community PR, not just this one. The workflow's recent successes are all upstream branches (pr3378, pr3379) which do have write access, and the other fork PRs (patch-1, test-config-search-path-str) are still sitting at action_required, so this PR appears to be the first fork PR where the job actually ran and hit it.

Happy to file this as a separate issue if useful — I have left it out of this PR to keep the change scoped to #3369.