[huntie]

Summary

Context

Follow-up to #59194, which pads the content container across the scrollable axis for every contentInsetAdjustmentBehavior except 'never'.

Motivation

Before this diff, 'automatic' and 'scrollableAxes' did the same thing. UIKit's .automatic differs from .scrollableAxes only by a backward-compatibility rule tied to automaticallyAdjustsScrollViewInsets, deprecated since iOS 11.

This diff

Pad across the scrollable axis for 'automatic' and 'always' only, so 'scrollableAxes' applies the safe area insets along the scrollable axis alone, as its name and UIKit's .scrollableAxes say.

Value	Along the scrollable axis	Across it
'never'	No insets	No insets
'scrollableAxes'	UIKit content inset	No insets, as in UIKit
'automatic'	UIKit content inset	Content container padded
'always'	UIKit content inset	Content container padded

• 'scrollableAxes' becomes a plain UIKit passthrough, and the opt-out for apps that handle the side insets themselves.
• The contentInsetAdjustmentBehavior docs now describe each value.

Changelog:
[Internal] - Narrows the cross-axis padding from #59194 to 'automatic' and 'always' before release

Test Plan

RNTester, ScrollView > Content Inset Adjustment Behavior, full screen modal, switching the behavior with the buttons at the top. Before is #59836; after is this PR, both built from source. These are unframed simulator captures.

iPhone Duo folded, scrollableAxes, before	after
Cards stop 20 pt short of the rail, the same as automatic	✅ Cards keep the container's 20 pt and run under the rail, as with UIKit's .scrollableAxes

iPhone 18 Pro landscape, scrollableAxes, before	after
Cards sit clear of both side insets	✅ Cards keep the container's 20 pt from the screen edge, inside the side insets

iPhone Duo folded, after, automatic	after, always
✅ Unchanged: cards clear of the rail	✅ Unchanged: cards clear of the rail

ℹ️ Switching between the values on a running screen updates the layout in both directions.

[huntie]

@huntie-bot If merged before Monday, pick to 0.88 and 0.89 — again citing via an > [!Important] callout that this depends on the other corresponding pick requests for the 2x commits in this stack.

[huntie]

@cipolleschi Updated, thanks