feat(iOS, Tabs): support active nested content scroll view markers

[Miyou]

Summary

This extends ScrollViewMarker so Tabs can bind their content scroll view to an explicitly active nested descendant instead of relying only on first-descendant or visibility heuristics.

This is aimed at layouts where tab content is wrapped by non-scroll containers and multiple descendant ScrollViews stay mounted at once, for example paged day views. In those cases the tab bar can stay attached to the first registered scroll view, which breaks minimize behavior and repeated-selection scroll-to-top for the currently visible page.

Changes

• add active?: boolean to ScrollViewMarker
• let RNSScrollViewMarkerComponentView notify seeking ancestors when active state changes
• teach RNSTabsScreenComponentView to track registered descendant scroll views by marker and prefer the active one in findContentScrollView
• use the resolved content scroll view for tab edge effects and content inset adjustment overrides
• call setContentScrollView(_:forEdge:) from RNSTabsScreenViewController so UIKit observes the resolved nested scroll view for the tab bar
• refresh the observed content scroll view when the selected tab controller updates
• add an iOS scenario that reproduces a nested, pager-like layout where multiple marked descendant scroll views remain mounted under a non-scroll wrapper
• add a no-op Android active setter to keep the prop surface aligned

Context

This follows the direction discussed in #3463 and builds on the marker work from #3674.

Validation

• yarn check-types
• manual downstream validation in a local Expo Router app using native tabs + nested paged scroll views: tab bar minimize behavior now follows the active page's vertical scroll view instead of staying attached to the first page

[Miyou]

Rebased onto current main and adapted the patch to the recent iOS tabs changes around moreNavigationController from #3785 and #3813. The branch is mergeable again.

[kkafar]

Hey @Miyou. Thanks for the PR.

Support for content scroll view handling on both platforms is exactly what we introduced the ScrollViewMarker component for, so you read that correctly & we'll likely proceed with this PR, but it'll take us a week or two more before we have a capacity. Our priority right now is Tabs API stabilisation (among few other things) & after that's done - this is next on the list.