This logic is described in the test as looking for a scroll ending
very close to a new page, but in fact its behavior is more like
"very close to a page to the right": if we're not very, very close
to any page, it will pick the page to the left, not an old page.
There's no reason this should be left-right asymmetrical.
Instead, pick the nearest page.
In practice, the case where this makes a difference never arises when
the scroll runs undisturbed to completion; but when the user taps on
the page to hold or drag, the scroll will be interrupted before it
gets within tolerance of a particular page, and this case does arise.
This fixes a glitch that is hard to trigger without time dilation,
but is quite conspicuous with it:
* Open a tab view with at least 4 tabs, e.g. the Buttons screen
of the gallery (with "Animate Slowly" on.)
* Starting at tab 0, tap tab 2.
* When the animation is nearly complete, tap the page a couple
of times, as if to drag it around to scroll. Then let the
page view settle ballistically toward page 2.
* Before it finishes, tap tab 3.
* Suddenly page 1 fills the view, replacing page 2, before we
scroll from there to page 3.
With this fix, the animation in the last step moves smoothly from
where we are when it starts onward to page 3.
84f5b1cb09