fix: prevent forcing new architecture off with --only-pods

[floydkim]

Summary

This PR fixes a New Architecture propagation issue in iOS pod installation for build-ios --only-pods / --force-pods.

Background

While testing --only-pods, I observed that a New Architecture-enabled project (RN 0.81, Reanimated v4) could run pod install with RCT_NEW_ARCH_ENABLED=0, causing installation failure.

[!] Invalid `RNReanimated.podspec` file: [Reanimated] Reanimated requires the New Architecture
to be enabled. If you have `RCT_NEW_ARCH_ENABLED=0` set in your environment you should remove it..

This was not limited to projects using Reanimated v4; even without Reanimated, projects that relied on RN defaults for enabling New Architecture could still have --only-pods/--force-pods effectively run with New Architecture disabled due to forced env handling in this path.

Problem

In the --only-pods/--force-install pod install flow, New Architecture intent was not handled properly when architecture detection was unavailable.

The detection logic relied on Pods/Pods.xcodeproj/project.pbxproj. On first pod install (before Pods are generated), this file may not exist yet. In that state, the flow could force RCT_NEW_ARCH_ENABLED=0, causing pod install to run as if New Architecture were disabled.

Changes

• Kept force-install behavior consistent so New Architecture intent is propagated correctly in the --only-pods / --force-pods path.
• Changed iOS architecture detection to treat missing Pods metadata as unknown (instead of defaulting to false).
• Updated pod install env handling to inject RCT_NEW_ARCH_ENABLED only when architecture is known; when unknown, the variable is omitted so Podfile/RN defaults are respected.
• Updated related doctor output mapping for unknown iOS architecture state.

And also updated CONTRIBUTING.md to include cli-config-android and cli-config-apple in the yarn link example, so local-link tests also cover config package changes.

Test Plan

Unit tests

• Added regression tests covering New Architecture propagation in the iOS pod install flow, including force-install behavior, unknown architecture detection handling, conditional env injection, and related doctor reporting.

Linked local CLI validation (per CONTRIBUTING.md)

Validated with newly created template apps and linked local CLI packages (yarn link-packages + yarn link ... in app):

1. RN 0.81.5 template + Reanimated v4

   • Unlinked (published CLI): npx react-native build-ios --only-pods failed with New Architecture disabled error.
   • Linked (this branch): same command succeeded.

2. RN 0.82.0 template + Reanimated v4

   • Unlinked (published CLI): npx react-native build-ios --only-pods failed with New Architecture disabled error.
   • Linked (this branch): same command succeeded.

Checklist

• Documentation is up to date.
• Follows commit message convention described in CONTRIBUTING.md.
• For functional changes, my test plan has linked these CLI changes into a local react-native checkout (instructions).

[thymikee]

At this point we should just drop the flag. New architecture is the default for a few RN versions now, and if you're still on old arch, you're likely on older RNC CLI version. I'll happily accept PR dropping it (few lines change, no need this many tests)

[floydkim]

@thymikee Thanks for the guidance.
I was also unsure whether injecting this flag is still necessary.
Just to clarify, should we remove the CLI-side injection of RCT_NEW_ARCH_ENABLED for pod install and rely on the project/RN defaults instead?

[thymikee]

yes

[floydkim]

Thanks for confirming. I’ll close this PR and open a new one that simply drops RCT_NEW_ARCH_ENABLED injection.