[iOS][SPM] Derive the generated manifests' iOS platform floor from the app

[chrfalch]

Summary:

The SwiftPM manifests React Native generates — the Autolinked aggregate, the per-dependency synth packages, and the scaffolded community packages — hardcoded platforms: [.iOS(.v15)]. SwiftPM refuses to link a product whose minimum platform is above the depending target's, so any self-managed package with a higher floor could not be autolinked. Every Expo package declares iOS 16.4, so a stock Expo app on 0.87.1 fails at build time with:

error: The package product 'Expo' requires minimum platform version 16.4 for the iOS platform,
       but this target supports 15.0 (in target 'AutolinkedAggregate' from project 'Autolinked')

The app itself is correct (IPHONEOS_DEPLOYMENT_TARGET = 16.4); the only disagreement was the generated manifests.

The floor is now the app's own IPHONEOS_DEPLOYMENT_TARGET, read from the injected .xcodeproj:

• Target selection: the injection marker's targetUuid, else the application target named by --product-name, else every application target.
• Per configuration: the target's own value, else the project-level configuration of the same name. The lowest value wins, since one manifest floor has to hold for every configuration.
• Clamped to React Native's minimum (15.1, min_ios_version_supported) and emitted in string form (.iOS("16.4")), because the .vNN enum form cannot express a minor version.

setup-apple-spm.js resolves the value once per add/update/sync/scaffold run, logs it (iOS deployment target: 16.4 (from MyApp.xcodeproj)), and passes it to the generator, the sync script, and the scaffolder via a new --ios-deployment-target flag. The flag value is sanitized at the generator boundary as well. SCAFFOLDER_VERSION is bumped to 20 so existing scaffolds regenerate with the new floor.

A floor set in an .xcconfig the configuration is based on is honored, including #include chains (target literal → target xcconfig → project literal → project xcconfig). A floor supplied through a build-setting variable ($(MY_FLOOR)) is not resolved and falls back to the minimum; the log line says so. spm add and spm update also refresh the platforms: element of existing scaffolded manifests (those carrying the scaffolder marker, including the pre-v20 .iOS(.v15) form, over the same expanded dependency set the scaffolder uses, transitive SwiftPM dependencies included) without creating new scaffolds or touching anything else in them.

Known limitation, documented in scripts/spm/__docs__/spm-scripts.md: the project file is not one of the auto-sync build phase's staleness inputs, so a deployment target changed after spm add takes effect on the next spm update.

The default floor moves from 15.0 to 15.1 for apps without a readable project setting; React Native already requires 15.1 for the app target, so this is not observable.

Changelog:

[IOS] [FIXED] - SwiftPM: generated manifests derive their iOS platform floor from the app's IPHONEOS_DEPLOYMENT_TARGET instead of hardcoding iOS 15, so dependencies with a higher minimum (e.g. Expo, 16.4) can be autolinked

Test Plan:

Unit tests were written first and seen failing, then made green:

yarn jest --no-cache -i packages/react-native/scripts/spm
Test Suites: 37 passed, 37 total
Tests:       1733 passed, 1733 total

New/updated coverage: ios-deployment-target-test.js (pbxproj reading: target-level, project-level fallback, xcconfig chain with #include and <group> anchoring, minimum across configurations, marker/--product-name/all-targets selection, invalid values, clamping, unreadable project), scaffold-package-swift-test.js (emitted floor, refresh of existing scaffolded manifests), generate-spm-autolinking-test.js (aggregate and synth templates, --ios-deployment-target through main()), scaffold-package-swift-test.js, sync-spm-autolinking-test.js (flag forwarding), setup-apple-spm-test.js (resolution and log line).

ESLint (--max-warnings 0), Prettier, and Flow are clean on the touched files.

Not run here: an end-to-end Xcode build of an Expo app on this branch. The failing scenario and the fix were verified by the Expo team against 0.87.1 with the same manifest change patched in locally (build proceeds past SwiftPM resolution into compiling Expo).

🤖 Generated with Claude Code

[cipolleschi]

A couple of questions about deployment-target propagation:

[cipolleschi]

Thanks for addressing the earlier feedback! Could you please also rebase this PR onto the latest main? It is currently showing merge conflicts.