fix(scroll): read initialScrollIndex offset after layout recompute

[naqvitalha]

Description

When initialScrollIndex is set and items have highly variable heights, items would overlap or the screen would appear blank. The root cause was in applyInitialScrollAdjustment() — the scroll offset for the target item was captured before recomputeLayouts(0, initialScrollIndex) ran. The recompute re-estimates unmeasured items with updated average heights (which shift as real measurements come in), changing the target item's y position. The stale offset created a mismatch between the EngagedIndicesTracker's scroll position and actual item positions, causing the wrong items (or none) to be rendered during progressive rendering.

The fix moves the offset read to after the recompute so the scroll offset always reflects the target item's actual position. Also fixes a minor operator precedence issue in the nullish coalescing fallback (initialItemOffset ?? 0 + this.firstItemOffset was evaluated as initialItemOffset ?? (0 + this.firstItemOffset)).

Fixes #1797

Reviewers' hat-rack 🎩

• The core change is a single method in RecyclerViewManager.ts — focus on whether reading the offset after recomputeLayouts is always correct, including for the else branch (no initialScrollIndex).
• Consider edge cases: horizontal lists, lists with ListHeaderComponent (non-zero firstItemOffset), and maintainVisibleContentPosition.startRenderingFromBottom.

Test plan

• Unit tests pass (yarn test — 183 tests)
• Type check passes (yarn type-check)
• Lint passes (yarn lint)
• Verified on iOS simulator — repro screen with 200 items (heights 40-500px) and initialScrollIndex=50 now correctly starts at Item 50
• No regressions on Grid (initialScrollIndex=25) or HorizontalList (initialScrollIndex=2)
• Scrolling up/down from the initial position renders all items without overlap or blank space