fix(android): detect newArchEnabled at subproject scope

[jmalmo]

What I changed

I switched isNewArchitectureEnabled() from rootProject.hasProperty(...) to project.hasProperty(...) in android/build.gradle and the example app's helper.

I also dropped newArchEnabled=true from example/android/gradle.properties to pin the regression — the existing build-android job in ci.yml now exercises the same code path real consumers hit.

Why

I hit this on a fresh React Native 0.83 / Expo SDK 55 dev-client app with react-native-emoji-popup installed. bun android failed at :app:configureCMakeDebug[arm64-v8a]:

CMake Error at .../Android-autolinking.cmake:
  add_subdirectory given source
  ".../node_modules/react-native-emoji-popup/android/build/generated/source/codegen/jni/"
  which is not an existing directory.

After digging in: on RN >= 0.82 the new architecture is mandatory and newArchEnabled is no longer required to live in gradle.properties. React Native's ReactRootProjectPlugin instead sets the property on each subproject's extraProperties. The current rootProject-scoped check misses that path — the lib silently skips apply plugin: "com.facebook.react", no codegen tasks register, and the consumer build dies during CMake configure. The same trap fires after a stale, non---clean Expo prebuild where the existing gradle.properties stays put and never picks up the new template's content.

project.hasProperty(...) covers all three cases without dropping legacy-arch support:

• RN >= 0.82 — finds the property via ReactRootProjectPlugin's subproject extraProperties.
• Legacy RN with explicit opt-in — gradle.properties values propagate to every project, so project.hasProperty(...) still returns true.
• Legacy RN without opt-in — neither scope carries the property, the gate stays closed, and the src/oldarch source path is preserved.

I considered going the more aggressive route and deleting the gate entirely (mirroring callstack/react-native-pager-view#1047), but peerDependencies are still permissive (react-native: "*") and src/oldarch exists, so the conservative fix felt right. Happy to switch if you'd prefer the harder line.

Test plan

The diff removes newArchEnabled=true from example/android/gradle.properties, so the existing build-android job in ci.yml now fails on main (the lib skips codegen) and passes with this PR. I verified locally with the same command CI uses:

yarn turbo run build:android

Result: BUILD SUCCESSFUL in 1m 45s. :react-native-emoji-popup:generateCodegenArtifactsFromSchema registered and ran, :app:configureCMakeDebug[arm64-v8a] completed, and :app:bundleDebug succeeded.

Other checks I ran:

• yarn install — green.
• yarn typecheck — green.
• yarn lint — green (only pre-existing inline-style warnings in example/src/App.tsx, untouched by this PR).
• yarn test — green (existing 1-todo Jest suite passes).
• yarn prepare (Bob build) implicitly verified via the build-library job equivalent during yarn install.

Notes

• Targets main. No spec/test removals, no unrelated edits.
• Same fix pattern as mrousavy/nitro#1314, which I opened earlier today for the same root cause in react-native-nitro-modules.