The `SPMIntegration` scheme in `SPMCustomEntitlementComputationInstallation` had
an empty `<BuildAction>` and a dangling `<LaunchAction>` reference to a
non-existent `SPMInstallation.app` target. That meant
`xcodebuild -showBuildSettings -scheme SPMIntegration` returned no settings
at all (no `BUILT_PRODUCTS_DIR`, no `SUPPORTED_PLATFORMS`).

Until fastlane 2.233.1 this was masked: scan silently fell back to
`File.expand_path("../../..", nil)` as `derived_data_path`, which happened
to be a writable path on CI, so the test ran and scan found the
`.xcresult`. fastlane 2.234.0 (PR fastlane/fastlane#22231) added an
explicit nil-guard in `Scan::DetectValues.default_derived_data`, so
`derived_data_path` is now left unset. `xcodebuild test` then uses its
default `~/Library/Developer/Xcode/DerivedData/...`, scan can't find the
result bundle there, and the installation test fails with
"Cannot find .xcresult in derived data which is needed to determine test
results" even though the test itself passes.

Fix the scheme to match the pattern already used by other test-only
schemes in the repo (e.g. `BackendIntegrationTests.xcscheme`):

- Add a `<BuildActionEntry buildForTesting="YES" .../>` for the
  `SPMInstallationTests.xctest` target so the scheme has a real buildable.
- Replace the dangling `SPMInstallation.app` reference in
  `<LaunchAction><MacroExpansion>` with the test bundle (the app target
  doesn't exist in this project).
- Declare `SUPPORTED_PLATFORMS = "iphoneos iphonesimulator"` on the test
  target so `xcodebuild -showBuildSettings -scheme` resolves cleanly
  regardless of Xcode version.
- Drop the now-unnecessary Scanfile workaround
  (`skip_build(true)` + accompanying comment) — the scheme is no longer
  "only setup for testing, not building".

Co-authored-by: Cursor <cursoragent@cursor.com>

The previous commit added the test bundle to the scheme's <BuildAction>
to fix `xcodebuild -showBuildSettings` returning empty settings. That
worked in theory, but in practice CI showed that once xcodebuild has a
buildable in the scheme it enforces scheme-level destination validation
against the test target's effective platforms, and rejects iOS Simulator
destinations:

    xcodebuild: error: Unable to find a destination matching the
    provided destination specifier:
            { platform:iOS Simulator, id:... }
    Available destinations for the "SPMIntegration" scheme:
            { platform:visionOS Simulator, ...Designed for [iPad,iPhone]... }

The empty <BuildAction> in the original scheme was effectively the
escape hatch that let fastlane pass an iOS Simulator destination and
have it accepted. Removing that escape hatch broke the build.

Revert the scheme and project.pbxproj changes back to main and instead
fix the real symptom: tell `fastlane scan` where to put / find derived
data. Once `derived_data_path` is set, `Scan::DetectValues
.default_derived_data` short-circuits before the
`BUILT_PRODUCTS_DIR is nil` early-return introduced in
fastlane/fastlane#22231 (fastlane 2.234.0), and the `.xcresult` lookup
works the same way it did under 2.233.1.

Use the same value (`scan_derived_data`) that the BackendIntegrationTests
and v3/v4 LoadShedderIntegration lanes already use in `fastlane/Fastfile`.

Co-authored-by: Cursor <cursoragent@cursor.com>