fix(layout): keep layout table monotonic on initial scroll

[ahmdshrif]

Description

Fixes #2307.

With initialScrollIndex set and items whose real size exceeds the layout managers' default 200px average estimate, the list opens showing the wrong items (e.g. item 333 instead of 250 with 300px items).

Root cause: applyInitialScrollAdjustment recomputes layouts only over 0..initialScrollIndex before reading the target offset. When the average estimate has been updated by a first measurement, that pass moves items 0..initialScrollIndex to new (larger) positions, while items beyond initialScrollIndex keep positions derived from the old estimate. The layout table becomes non-monotonic at the initialScrollIndex boundary (e.g. 75,000 → 50,400), and the binary search over item positions then resolves the scroll offset to the wrong region of the table.

The fix recomputes the entire table in this pass, keeping it monotonic. This path only runs during the initial progressive-render passes (renderProgressively until the first layout completes), and the recompute is a simple position chain, so the cost class is unchanged from the existing 0..initialScrollIndex pass.

Reviewers’ hat-rack

• The measurement path (modifyLayout) already recomputes to the end of the table when items are appended; only this initial-scroll corrective pass stopped early.
• Items smaller than the estimate don't trigger the bug (the corrective pass moves items to lower positions, which keeps the table sorted) — matching the issue's observation that only sizes > 200px reproduce it.

Test plan

• New test src/__tests__/InitialScrollIndexLargeItems.test.tsx: 500 items measuring 300px with initialScrollIndex={250}.
  • Before the fix it fails exactly as reported in Flashlist v2 initialScrollIndex renders wrong items when item size exceeds 200 #2307: items 333–335 are rendered instead of 250.
  • After the fix item 250 renders.
• yarn test --forceExit — 15 suites, 188 tests pass.
• yarn type-check and yarn lint — clean.

[ahmdshrif]

I've signed the CLA.