Stop the host Hermes compiler build from targeting visionOS

[kraenhansen]

Fixes the Hermes prebuilt workflow, which had failed on every run (1, 2, 3) with:

CMake Error at external/llvh/cmake/modules/CheckAtomic.cmake:53 (message):
  Host compiler appears to require libatomic, but cannot find it.

Verified: run 31719660147 on this branch built Hermes in 26m46s and published the first asset — hermes-5a795c9f8800-rn0.88.0-nightly-20260809-db662caea-debug-iphoneos-iphonesimulator-arm64.tar.gz, 118 MB, into the release the first failure had left empty.

The actual cause

buildArchive exported all three deployment targets build-apple-framework.sh can ask for to every command it ran, including the host compiler configure. XROS_DEPLOYMENT_TARGET is not only the name that script reads — it is also a clang driver variable. With it set and no explicit target, clang built for visionOS:

clang: warning: using sysroot for 'MacOSX' but targeting 'XR' [-Wincompatible-sysroot]
/…/MacOSX.sdk/usr/include/sys/_types/_fd_def.h:64:18: error:
  '__darwin_check_fd_set_overflow' is unavailable: not available on visionOS
/…/c++/v1/__thread/support/pthread.h:54:14: error:
  'pthread_mutexattr_init' is unavailable: not available on visionOS

Every feature check touching an API marked unavailable on visionOS failed, and CMake reports those as a bare not found. That is what made this hard to read from the console log: unistd.h reported missing while sys/stat.h did not, which looks impossible until you see that unistd.h reaches _fd_def.h through sys/select.h and sys/stat.h doesn't. CheckAtomic was simply the first such check that treats failure as fatal.

Each platform build now gets only the deployment target that platform needs, and the host compiler build gets none. This also explains why React Native's own [RN] [1] Build Hermesc never hit it: that runs its CMake under env -i, so nothing from the job environment reaches clang.

How it was found

Two earlier attempts were guesses from console output and both were wrong — first CMAKE_OSX_ARCHITECTURES (#442, removed on a hypothesis that turned out not to be the cause; that change is still worth keeping for the archive-naming reasons in its own description), then a suspicion about inherited environment in general, right in shape but not actionable without knowing which variable.

What settled it was the failure-only diagnostic added here: it dumps CMake's CMakeConfigureLog.yaml, where the compiler's real complaint lives, plus the job environment, xcode-select -p and the SDK path, and uploads the full log as an artifact. Those steps are kept — this configure was misdiagnosed twice from the console log alone, and they turn the next occurrence into one round trip.

A useful control along the way: the identical configure succeeds on Linux against the same pinned Hermes (every header found, HAVE_CXX_ATOMICS_WITHOUT_LIB - Success), which ruled out the Hermes source, the pin and the CMake arguments.

Test plan

• Hermes prebuilt dispatched on this branch gets past the host compiler and publishes an asset
• The published asset name round-trips: GitHub stored it byte-identical to what --print name produces, and the URL --print url composes serves a valid gzip
• Use the prebuilt Hermes archive for iOS builds #441 is restacked on this branch — its Test app (iOS) should now download the asset rather than build