CI: cover the prebuilt RNCore Debug/Release configuration switch on iOS

[chrfalch]

Summary

Adds one CI lane, test-ios-prebuilt-config-switch.yml, that builds a template app in Release on top of a Debug prebuilt-RNCore install — the situation that produced #57803.

Nothing in CI runs packages/react-native/scripts/replace-rncore-version.js today:

• the SwiftPM lanes never invoke it;
• e2e-ios-templateapp.yml is the only CocoaPods prebuilt lane, and it exports RCT_TESTONLY_RNCORE_TARBALL_PATH;
• React-Core-prebuilt.podspec adds the [RNCore] Replace React Native Core for the right configuration, if needed script phase only when that variable is absent.

So the phase never exists in CI. That is why #57803 shipped in 0.87.0-rc.2 and survived rc.3.

What it guards

1. A template app installed with prebuilt RNCore through the regular resolution path — no RCT_TESTONLY_RNCORE_TARBALL_PATH, so the script phase is really there.
2. scripts/e2e/fixtures/RNCoreConfigSwitchProbe, a pod with one .m file and no spec.dependency. Without a dependency on React-Core-prebuilt there is no target-dependency edge ordering it behind the script phase, so its compilation can overlap with whatever that phase does to Pods/React-Core-prebuilt. Real apps hit this through FirebaseCore, GoogleUtilities, SDWebImage and friends.
3. Debug written to Pods/React-Core-prebuilt/.last_build_configuration, then a Release build with empty DerivedData.

Dropping RCT_TESTONLY_RNCORE_TARBALL_PATH puts artifact resolution back on the download path, and a CI version is never published on Maven. scripts/e2e/local-maven-mirror.py therefore serves this run's two flavor tarballs under their published names via ENTERPRISE_REPOSITORY, and redirects every other lookup (Hermes included) to Maven Central — so Hermes keeps resolving its prebuilt release tarball exactly as it does today.

Two asserts run after pod install, because a lane that silently falls back to a source build is how this bug got through in the first place:

• Pods/React-Core-prebuilt/Headers/module.modulemap exists;
• replace-rncore-version.js appears in Pods/Pods.xcodeproj/project.pbxproj.

Test plan

Verified locally:

• Running ReactNativeCoreUtils.setup_rncore + resolve_podspec_source against the local mirror with an unpublished version 1000.0.0-deadbeef gives build_from_source = false, a pod source pointing at the mirror, and both reactnative-core-1000.0.0-deadbeef-{debug,release}.tar.gz in Pods/ReactNativeCore-artifacts/ — the exact names replace-rncore-version.js computes. Without the mirror the same version logs No prebuilt artifacts found, reverting to building from source, which is what the two asserts catch.
• The mirror returns 200 for a local hit, and redirects the current HERMES_VERSION_NAME lookup to Maven Central (200). A missing .sha1 sidecar makes validate_tarball skip validation instead of failing.
• Both asserts and the Podfile edit were checked against a real installed prebuilt app: the module map and the script phase are at those paths, and a dependency-free local pod does get -fmodule-map-file=$(PODS_ROOT)/React-Core-prebuilt/Headers/module.modulemap in its xcconfig.
• YAML parses, prettier --list-different is clean.

Not verified: I did not run the full lane end to end, so I have not observed it go red on main and green with #57814. The reproduction it encodes is the one reported in #57803 and confirmed by hand on Xcode 26.3 (Debug→Release switch fails with a dependency-free pod; passes once that pod depends on React-Core, or is removed).

Expect this lane to be red until #57814 lands — that PR is the fix; this PR is the missing coverage. Please land #57814 first.

🤖 Generated with Claude Code