feat(spm): rename legacy <App>.xcodeproj on init so npm run ios picks SPM

The community CLI (@react-native-community/cli-config-apple v20.1.0) hardcodes
xcodeproj discovery to findXcodeProject(readdirSync(sourceDir)), which sorts
alphabetically and returns the first entry whose extname is `.xcodeproj`.
With the legacy CocoaPods <App>.xcodeproj and the generated <App>-SPM.xcodeproj
both in ios/, the legacy wins ('.' > '-' in ASCII) — so `npm run ios` always
built the CocoaPods project after migrating to SPM. The CLI accepts no
--project flag and ignores userConfig.xcodeProject in react-native.config.js,
so there's no in-band override.

Solution: on `spm init`, offer to rename <App>.xcodeproj → <App>.xcodeproj.legacy.
The .legacy extension is invisible to findXcodeProject's heuristic, leaving the
SPM xcodeproj as the only match. The legacy directory stays on disk for
rollback (`mv MyApp.xcodeproj.legacy MyApp.xcodeproj`); `git mv` tracks the
rename cleanly. Declining keeps both side-by-side and falls through to the
existing Podfile-patch flow that pins CocoaPods to the legacy project.

- New pure helper decideLegacyMigration(appRoot): returns one of `rename` /
  `skip-no-legacy` / `skip-already-migrated` / `skip-conflict` so the orchestrator
  can log and act without re-implementing the state machine.
- maybeMigrateLegacyXcodeproj(args, appRoot): prompts ([Y/n], default-yes,
  --yes bypass), executes the rename, narrates per-case.
- Wired into main() on `init` only, BEFORE generateXcodeProject so the new
  SPM xcodeproj appears alongside the already-renamed legacy.
- Updated Podfile-patch comment to clarify it only fires when the user kept
  both xcodeprojs (declined the rename).
- 7 new tests for decideLegacyMigration covering all four states + edge
  cases (missing appRoot, SPM-only, multi-xcodeproj).
- File header doc updated with the migration explanation.

Author: chrfalch