scroll-to: up past the start pulls at most once and says it may have refreshed (CHALLENGES 310)

[lana-20]

A scroll loop ends a list with a swipe that moves nothing, and at the start of a list that swipe is a pull. On MobiumApp's Feed Demo, with pull to refresh added in mobiumdev/mobium-app#27, an upward search from Row 45, with sixty rows loaded, refreshed the feed and threw the loaded rows away. It said only "the end of the list".

What changed

• Stopping at the start: once a swipe toward the start moves the rows clearly less than the swipe before it, or not at all while something else moved (the spinner), and the first row is whole at the edge, the loop stops instead of swiping again. It compares against the previous swipe, not the swipe's own length, because swipes coast: on the simulator, twice their length.
• The loading wait: a busy indicator that came and went with nothing new is no longer taken for more rows. On iOS, the refresh spinner was waited out and the next swipe pulled again.
• The warning: a search that reaches the start says the last swipe there is a pull, which an app may answer by refreshing. It's in the text and as may_have_refreshed in the details. Whether the app refreshed can't be read from outside, so it's worded as a possibility.

Measured (from Row 45, swipes / refreshes, before → after):

Device	Before	After
iOS 26.5 simulator	8 / 2	6 / 0, rows kept
Pixel 8 Pro (Android 17)	7 / 2	6 / 0, rows kept
iPhone 15 Plus	8 / 2	6 / 1
Android 15 emulator	8 / 1	8 / 1

On the iPhone and the emulator, the swipe that reaches the start already pulls: 3 out of 3 on the emulator, from 300 px down. Nothing short of knowing where a list starts could avoid that one, and it's now reported.

Checks

• feed.sh asserts the warning and at most one pull per search. It passed on all four devices.
• Unit tests cover the measurement and the wording.
• make ci: 232 checks, 0 failed.