[MOO-2404] - fix intro screen - main

[YogendraShelke]

Problem

Three defects in how the IntroScreen decided which slide was showing:

• The slide on screen could stop following the buttons and slide indicators, so navigating showed the controls for one slide while the previous slide was still displayed. The Android e2e flow caught this as a missing FINISH button.
• Swiping slowly moved the slide without updating the indicators, the buttons or the active slide attribute.
• Where the active slide attribute already pointed at the slide the widget opened on, the first swipe was ignored and the slide swiped to sprang back.

Root cause

The widget was working out for itself which gesture phase ended a swipe. It rounded contentOffset.x / width in onMomentumScrollEnd and gated that behind a hand-kept isInitializing latch. Both halves were wrong:

• A drag lifted with no velocity produces no momentum phase at all, so a slow swipe was never reported. This is the slow-swipe defect.
• The latch existed to tell the list's own opening scroll apart from a real swipe, and it was cleared only inside the sync effect's slide !== activeIndex branch. Start with the attribute agreeing with the slide the widget opens on and that branch never runs, so the latch is never cleared, so the first swipe is swallowed — and the sync effect then scrolls back, reverting the slide the user swiped to.

Separately, @shopify/flash-list 2.x enables maintainVisibleContentPosition by default. It anchors the list to whichever item was first visible and, whenever a re-render moves that item, scrolls back by the difference. Navigating re-renders the slides, so that correction silently undid the scrollToOffset in goToSlide — state advanced, pixels did not. Confirmed on-device: after goToSlide(2) requested offset 822.86 (valid — content width 1234), onScroll reported x=0. Not a clamp, which would have given 411.

Fix

Which slide is showing is asked of the list through onViewableItemsChanged instead of inferred from offsets and gesture phases. flash-list computes viewability inside its own scroll handling, so a drag lifted with no velocity is reported like any other arrival, and waitForInteraction: true supplies the "not the initial scroll" distinction the widget was keeping by hand — flash-list already withholds reports until the first real interaction (RecyclerView.tsx only calls recordInteraction() once isInitialScrollComplete). itemVisiblePercentThreshold: 60 is unambiguous because slides are exactly one window wide; minimumViewTime: 250 keeps positions merely passed through from counting as arrivals.

Four gesture handlers, a manual dragging flag and a settle-timeout fallback are replaced by one handler.

Also in the same sync path:

• maintainVisibleContentPosition disabled — paged slides are all one window wide and every position here is asked for explicitly, so there is nothing to preserve.
• The list mounted before a width was known, laying every slide out at width zero and stacking them all on the first page. It now mounts once onLayout reports a width, with a measuring placeholder before that.
• initialScrollIndex was passed the live active index, so flash-list's post-mount re-apply raced our own scrollToOffset. The slide the list opens on is frozen once mounted.
• A write to the attribute round-trips through the runtime, so for a render or two it still reads the slide just left. Syncing from it scrolled straight back and overwrote the value just written.

Also in this PR

Maestro e2e. Swipes use explicit start/end points inside the slide: an edge-anchored swipe loses travel to the system back gesture, and the backward one fell short of halfway and snapped back to where it started — a flake independent of the widget fix. NEXT is what becomes FINISH on the last slide, so the flow now waits for the slide before reaching for the button.