feat: add support for dynamic frameworks

[Saadnajmi]

Summary

Improve support for building RNTester with dynamic frameworks (USE_FRAMEWORKS=dynamic), and add CI coverage that exercises it without blocking (matching upstream).

The core fix (folly)

Add folly/memory/SanitizeLeak.cpp to RCT-Folly.podspec's source_files. The file ships in the Folly source tree (fetched by CocoaPods) but was never compiled, so annotate_object_leaked_impl / annotate_object_collected_impl (declared in SanitizeLeak.h, referenced from small_vector.h) were undefined. With static libraries the linker drops them; with dynamic frameworks every symbol must resolve, so the build fails at link time. This is also an upstream bug — facebook/react-native marks its test_ios_rntester_dynamic_frameworks job continue-on-error for the same reason.

RCTUIKit: give it its own module namespace

RCTUIKit lives in the separate React-RCTUIKit pod (module React_RCTUIKit) but is imported everywhere as <React/RCTUIKit.h>. In static builds both React-Core and React-RCTUIKit use header_dir "React", so their headers pool into one Pods/Headers/Public/React dir and the include resolves. Under use_frameworks! each pod builds its own framework module, that shared dir vanishes, and <React/RCTUIKit.h> can't resolve.

• React-RCTUIKit now uses header_dir "React_RCTUIKit"; its internal sibling imports become <React_RCTUIKit/...> (which also breaks a React → React_RCTUIKit → React module cycle under frameworks).
• React-Core vends modular <React/RCTUI*.h> forwarding headers that #import <React_RCTUIKit/...> — so all ~195 existing <React/RCTUIKit.h> imports keep working, with no consumer changes and no -Wnon-modular-include error.
• SwiftPM prebuild links RCTUIKit under React_RCTUIKit too (in addition to React), so the new imports resolve there as well.

Additional dynamic-frameworks build fixes

• SUPPORTED_PLATFORMS per pod target (from SDKROOT) — without it the per-platform framework targets collide with hermes-engine's "Multiple commands produce".
• Set $RN_PLATFORMS before podspec evaluation so add_dependency() generates per-platform-suffixed framework header search paths (React-debug-iOS vs React-debug-macOS).
• Suffixed framework header search paths in the React-cxxreact, ReactCommon and React-NativeModulesApple podspecs (also corrects a React_featureflags.framework path that pointed at the React-debug dir).
• Expose react/renderer/components/view/platform/macos on React-Fabric's framework header search paths (fork compiles those macOS view files on all platforms; they include KeyEvent.h).

CI

Add a linkage: [static, dynamic] dimension to the RNTester build matrix (macOS/iOS/visionOS × oldarch/newarch). Dynamic-frameworks jobs are continue-on-error (upstream-aligned) — they report status without blocking; static builds stay required.

Verified locally

• Static RNTester iOS build passes (required).
• Dynamic build resolves RCTUIKit with zero cyclic / non-modular / not-found errors.

Remaining (tracked, non-blocking on the dynamic canary)

A few dynamic-only header-search-path gaps (folly/dynamic.h, RCTFabricSurface, ComponentDescriptors) and a genuinely macOS issue (HostPlatformViewEventEmitter.cpp uses AppKit-only MouseEvent types while compiling on iOS). These keep the dynamic jobs red, which is why they're continue-on-error.

Test plan

• RNTester static builds pass on macOS, iOS, visionOS (required)
• Prebuild macOS Core (SwiftPM) passes
• Dynamic-frameworks jobs run and report status (non-blocking)