Use $(PODS_ROOT) for the VFS overlay flag in aggregate and third-party xcconfigs

[janicduplessis]

Summary:

configure_aggregate_xcconfig interpolates the absolute resolved path of React-VFS.yaml into every aggregate and third-party pod xcconfig:

vfs_overlay_flag = " -ivfsoverlay \"#{vfs_overlay_path}\""

while add_rncore_dependency in the same file already emits the identical flag as $(PODS_ROOT)/React-Core-prebuilt/React-VFS.yaml for podspec-processed pods. The absolute form is the only thing tying those generated xcconfigs to the checkout that ran pod install: a Pods directory restored from a CI cache or cloned into a git worktree keeps resolving the original checkout's overlay for as long as that path exists, and fails without naming the real cause once it doesn't. In a bare RN 0.86.2 app this accounts for 168 absolute-path references across 28 pods' xcconfigs — every other path CocoaPods generates there is ${PODS_ROOT}-anchored.

This targets 0.86-stable directly because main no longer has the code: the prebuilt-core integration there dropped the VFS overlay entirely and its replacement already uses $(PODS_ROOT) throughout, so there is nothing to fix forward.

Changelog:

[IOS] [FIXED] - Use $(PODS_ROOT) instead of an absolute path for the VFS overlay flag in aggregate and third-party pod xcconfigs

Test Plan:

On a bare RN 0.86.2 app (prebuilt core, Expo SDK 57):

• pod install, then grep -r '/Volumes' 'Pods/Target Support Files': the 168 -ivfsoverlay "/abs/.../React-VFS.yaml" references become $(PODS_ROOT)/React-Core-prebuilt/React-VFS.yaml; combined with Expo-side fixes ([ios] Anchor generated Pods paths on ${PODS_ROOT} instead of absolute paths expo/expo#49251) the generated output reaches 0 absolute paths
• full xcodebuild of the app workspace succeeds
• cloned the checkout into a git worktree (carrying Pods/ verbatim, no pod install) and built with a fresh DerivedData: succeeds, with the expanded flag pointing inside the worktree instead of the original checkout

The install-time existence check above the patched lines still runs against the resolved absolute path, so the missing-overlay error path is unchanged.