fix(ios): keep pages out of the safe area again

[R4M80MrX]

Summary

#1085 dropped ignoreSafeArea: true from the hosting controller when it introduced propagateSafeArea(). Restoring it fixes pages being laid out inside the safe area on iOS, and does not undo what #1085 set out to fix.

The two mechanisms are independent:

• ignoreSafeArea: true (disableSafeArea()) keeps SwiftUI from shrinking and shifting the pages. PagerView's GeometryReader is measured inside the hosting view and each page is framed to proxy.size, so a hosting view that carries a safe area produces pages inset by it.
• propagateSafeArea() on PageChildViewController gives child UIKit views their insets back — the problem fix(ios): propagate safe area insets to child UIKit views inside PagerView #1085 was written for ([iOS] New Arch: safe area insets are stripped from PagerView children #1090, [iOS] v8 (SwiftUI TabView): pages shrink when the keyboard appears — real devices only #1096).

With the flag gone, the convenience initialiser it used, UIHostingController(rootView:ignoreSafeArea:), and disableSafeArea() became dead code; nothing in the repo calls them on main today.

What it looks like

Measured on an iPhone 17 Pro Max simulator (iOS 26.5, 440×956pt, safe area top 62 / bottom 34), New Architecture, react-native-pager-view 9.0.4, React Native 0.86.3. The app places the pager above an 83pt React Native tab bar, so React Native lays the pager out at y 0..873.

I put coloured borders on the views and read their positions off a screenshot:

view	React Native layout	on screen, before	on screen, after
PagerView itself	0 .. 873	0 .. 872.7 ✅	0 .. 872.7 ✅
its page container	0 .. 873	31.0 .. 810.7 ❌	0 .. 872.7 ✅

The pages lost ~93pt and sat 31pt low. Anything anchored to the bottom of a page — in this app a right-hand action rail and the author/caption row — was pushed off screen. onLayout inside a page still reported the full 873pt, so nothing on the JS side could compensate for it.

Relation to #1099

#1099 reports the same family of symptom on 8.0.4 and also points at #1085, but diagnoses a different mechanism: propagateSafeArea() sampling _UIHostingView<_ViewList_View>'s bottom inset mid-relayout, while it flickers 49 → 24.33, and pinning the transient value.

This change is not a fix for that sampling race, and I could not reproduce #1099's "corrects itself after the first scroll" behaviour — what I see is stable from the first render onwards. Zeroing the outer hosting view's insets may also remove an unstable source from the nearestNonZeroSafeAreaInsets() walk, but the view named in #1099 is an inner hosting view for the page list, which disableSafeArea() does not subclass. That part is worth a maintainer's eye.

Test Plan

What's required for testing (prerequisites)?

An iOS device or simulator with a home-indicator safe area, New Architecture, and a pager that is not itself inset — for example full-screen content behind a custom React Native tab bar.

What are the steps to reproduce (after prerequisites)?

1. Render a <PagerView> filling a screen whose top and bottom reach into the safe area.
2. Give a page content anchored to its bottom (position: 'absolute', bottom: 0).
3. Before: the anchored content is off screen and the page sits low, while onLayout on the page reports the full height.
4. After: the page matches React Native's layout exactly and the anchored content is visible.

Verified in the app this came from: the page container went from 31.0 .. 810.7 to 0 .. 872.7 with no other change. The diff is iOS-only, so Android is untouched.

Compatibility

OS	Implemented
iOS	✅
Android	n/a

Checklist

• I have tested this on a device and a simulator — simulator only (iPhone 17 Pro Max, iOS 26.5); not on physical hardware
• I added the documentation in README.md — not applicable
• I updated the typed files (TS and Flow) — not applicable