[piaskowyk]

Summary

Cherry-pick of facebook/react-native@ece0efe (facebook/react-native#57581) onto 0.86.0-discord, with the flag's default flipped from false to true.

enableMountingCoordinatorPullModelAndroid gates the Android pull-model mounting migration: the UI thread pulls the transaction itself via a PullTransactionMountItem enqueued in the MountItemDispatcher, rather than the commit thread pulling and building the mount batch in schedulerShouldRenderTransactions.

Two commits, so the upstream import and the Discord-specific default change stay reviewable apart:

1. Add enableMountingCoordinatorPullModelAndroid feature flag (#57581) — the upstream cherry-pick, unchanged in behavior.
2. Default enableMountingCoordinatorPullModelAndroid to true — the Discord default flip.

This is inert on this branch today

Worth being explicit, since the flag name suggests otherwise: flipping this default currently has no runtime effect. The upstream commit is flag-definition-only, 20 files of feature flag plumbing. There are no consumers of the flag in this branch, nor upstream at ece0efe. The implementation it gates lands in later upstream commits that are not cherry-picked here. PullTransactionMountItem appears in this tree only inside the flag's own description string.

The default is set to true now to record intent, so the path is on once the implementation is backported.

Relationship to usePullModelOnAndroid

This is a different, later migration than the pull model this fork already runs. usePullModelOnAndroid already defaults to true here and does have real consumers in FabricUIManagerBinding.cpp and FabricUIManager.java. Upstream has since removed that flag entirely, having graduated it. The new flag moves the pull down into the MountingCoordinator.

Dependencies to check before the implementation is backported

The flag description names prerequisites. Current state on this branch:

Flag	Current default	Required
enableAccumulatedUpdatesInRawPropsAndroid	true	always
enableExclusivePropsUpdateAndroid	false	when Props 2.0 is in use
enablePropsUpdateReconciliationAndroid	false	when Props 2.0 is in use

The latter two are still off, so they need revisiting when the migration actually turns on.

Notes on the cherry-pick

The generated feature flag files conflicted, because this fork's flag set has diverged from upstream (the fork carries extra flags, so flag ordering and the markFlagAsAccessed indices differ). Rather than hand-merging 19 generated files, I kept the fork's versions, applied the upstream change to ReactNativeFeatureFlags.config.js (which merged cleanly), and regenerated with yarn featureflags.

The resulting diff outside the config is exactly what you would expect: the new flag's accessors, the markFlagAsAccessed index shift for every alphabetically later flag, the accessedFeatureFlags_ array growing from 98 to 99, and updated SignedSource hashes. No existing flag was added, removed, or changed.

Neither app-side provider overrides the flag, so the default applies directly: ReactNativeNewArchitectureFeatureFlagsDefaults (Android) and ReactNativeFeatureFlagsOverridesOSSStable (iOS) both inherit it.

Test plan

• A re-run of the generator reports no pending changes
• Android builds