feat: add minScrollOffset so autoscroll respects non-reorderable header content

[alhansrisuk]

Summary

• The built-in top-edge autoscroll (useAutoScroll's isScrolledUp/isAtTopEdge) only disables itself once the list's scroll offset reaches absolute 0. That's correct for a list that's entirely reorderable, but not for one that mixes non-reorderable content (e.g. a ListHeaderComponent) with a reorderable section below it: dragging that section's own first item can put the dragged cell's on-screen position right at the container's top edge immediately, and the library scrolls back up into the header content — which was never part of the reorder.
• Adds minScrollOffset, an optional Animated.SharedValue<number> (default 0, so existing behavior is unchanged for anyone not passing it — this is purely additive/non-breaking) that lets a consumer tell autoscroll where the real top of the reorderable region is, so it stops there instead of continuing toward absolute 0.
• Same shape as the existing outerScrollOffset prop (an externally-supplied SharedValue the consumer keeps updated), so it should feel consistent with the library's existing API for this kind of thing.

This came out of building a queue-reorder feature: a single FlatList with Recently Played/Now Playing rendered via ListHeaderComponent (not reorderable) above an "Up Next" section (reorderable). Grabbing the first Up Next item would immediately trigger the built-in autoscroll and yank the list back up into that header content mid-drag.

Test plan

• yarn typecheck passes
• yarn test — same 3 pre-existing failures as main (a Reanimated.useEvent incompatibility unrelated to this change, confirmed by running the suite on unmodified main), no new failures
• Verified against a real-world repro (FlatList with non-reorderable header content above a reorderable section): setting minScrollOffset to the reorderable region's start stops the unwanted autoscroll/jump on grabbing the first item; omitting the prop leaves behavior unchanged from current main.