SafeAreaProvider, safe-area hooks, and SafeAreaView edges/mode

[Abbondanzo]

Summary:
Brings React Native core's safe-area API to functional parity with react-native-safe-area-context. This change adds the shared JS API and shared C++ layout logic, and wires up the Android native implementation (iOS follows in a subsequent change).

New public API (exported from react-native):

• SafeAreaProvider — measures the window safe-area insets and frame and provides them via context.
• useSafeAreaInsets() / useSafeAreaFrame() hooks, plus SafeAreaInsetsContext / SafeAreaFrameContext, withSafeAreaInsets HOC, and SafeAreaListener.
• initialWindowMetrics for synchronously seeding insets/frame to avoid a first-frame jump.

SafeAreaView gains edges (per-edge off / additive / maximum) and mode (padding | margin) props. The inset-to-padding/margin conversion lives in the shared C++ shadow node (SafeAreaViewShadowNode::adjustLayoutWithState) driven from the component descriptor's adopt, so iOS and Android share one implementation. On Android, SafeAreaView now reports insets into Fabric state without consuming them, so nested providers/views compute correctly, and a new native SafeAreaProvider component reports insets and frame to JS via an onInsetsChange event.

This targets the new architecture (Fabric).

Changelog:
[Android][Added] - Add SafeAreaProvider, useSafeAreaInsets/useSafeAreaFrame, and edges/mode props on SafeAreaView

Differential Revision: D111273335

[meta-codesync]

@Abbondanzo has exported this pull request. If you are a Meta employee, you can view the originating Diff in D111273335.

[zoontek]

@Abbondanzo I'm not sure useSafeAreaFrame / SafeAreaFrameContext are worth it, as we already can substract insets from window dimensions.

[slorber]

Just trying to understand: initially you wanted to remove SafeAreaView (#57395), but finally it stays in React Native core and will be improved?

[Abbondanzo]

Just trying to understand: initially you wanted to remove SafeAreaView (#57395), but finally it stays in React Native core and will be improved?

I wanted to understand the amount of work required it would take to fully support SafeAreaView, because quite a few internals still rely on it and I felt removing/deprecating the API was the wrong decision--the work required to support a limited subset of features for those internal use cases is not that different from this. I created this to share around with others, including the AppAndFlow team, as a proof-of-concept. I don't want to churn users, so I haven't published it or made an attempt to land it.

I'm still having chats with everyone to see if there's a way we can restore this API safely, but no new progress to share since most people are out on vacation this month and next (myself included).