Fix Hermes bytecode version mismatch in SwiftPM Release builds

[nduaarte]

Summary:

react-native spm add's Release builds crash on launch with:

Compiling JS failed: Wrong bytecode version. Expected 99 but got 98

This happens because the SwiftPM integration resolves the Hermes runtime
(the downloaded hermes-engine.xcframework) and the Hermes compiler (the
hermesc binary that turns the JS bundle into bytecode) from two independent,
unsynced sources:

• download-spm-artifacts.js's resolveHermesArtifact() picked the runtime
  by querying the hermes-compiler package's latest-v1 dist-tag on the npm
  registry live, at build time.
• generate-spm-xcodeproj.js's resolveHermesCliPathSetting() (and
  react-native-xcode.sh, for the CocoaPods-free fallback) points
  HERMES_CLI_PATH at the hermes-compiler package already installed in
  this project's own node_modules — whatever got pinned the last time
  npm install ran.

If the latest-v1 dist-tag advances on npm between npm install and the
Release build (which happens routinely as new Hermes builds are published),
the downloaded VM and the locally pinned hermesc fall out of sync and the
app crashes at launch. react-native-xcode.sh already documents this exact
invariant ("react native pins the hermes-compiler version, so the compiler's
bytecode version always matches the prebuilt hermes VM artifacts") — SwiftPM's
artifact download just wasn't honoring it.

This PR makes resolveHermesArtifact() read the pinned hermes-compiler
version from node_modules first (the same require.resolve lookup already
used for HERMES_CLI_PATH), so the runtime download and the compiler always
agree. It falls back to the previous latest-v1 npm lookup only when
hermes-compiler isn't locally resolvable (e.g. USE_HERMES=false apps that
never installed it). Explicit HERMES_VERSION overrides (nightly,
latest-v1, a literal version) are unchanged.

Fixes #57917.

Changelog:

[IOS] [FIXED] - Fix Hermes runtime/compiler version mismatch causing "Wrong bytecode version" crashes in SwiftPM Release builds

Test Plan:

Added unit tests covering the new local-resolution path, the fallback when
hermes-compiler isn't installed, and confirming existing HERMES_VERSION
overrides still take precedence over the local pin.

$ node_modules/.bin/jest packages/react-native/scripts/spm/__tests__/download-spm-artifacts-test.js
Test Suites: 1 passed, 1 total
Tests:       70 passed, 70 total

$ node_modules/.bin/flow check packages/react-native/scripts/spm/download-spm-artifacts.js
No errors!

$ node_modules/.bin/eslint packages/react-native/scripts/spm/download-spm-artifacts.js packages/react-native/scripts/spm/__tests__/download-spm-artifacts-test.js
(no output — clean)

$ node_modules/.bin/prettier --check packages/react-native/scripts/spm/download-spm-artifacts.js packages/react-native/scripts/spm/__tests__/download-spm-artifacts-test.js
All matched files use Prettier code style!

Reproduced the crash and confirmed the fix end-to-end using the public
reproducer linked from the issue
(https://github.com/marandaneto/react-native-087-swiftpm-hermes-bytecode-repro):

• Before the fix: npm run reproduce builds successfully but launching the
  app in the iOS Simulator crashes with Compiling JS failed: Wrong bytecode version. Expected 99 but got 98.
• After applying the equivalent fix to the reproducer's installed
  react-native copy: the log shows Using locally pinned hermes-compiler: 250829098.0.16, and both the debug and release Hermes runtime artifacts
  resolve to that exact version — matching the hermesc used for
  HERMES_CLI_PATH. xcodebuild ... -configuration Release succeeds, and
  the app installs and launches cleanly on an iPhone 17 Pro (iOS 26.5)
  simulator with no crash.

[cipolleschi]

Thanks for fixing this.

[meta-codesync]

@cipolleschi has imported this pull request. If you are a Meta employee, you can view this in D115859923.

[cortinico]

Review automatically exported from Phabricator review in Meta.