fix: Match mobile-web :hover behavior on touch

[MatiPl01]

Touch :hover now depends only on the touch-down and release locations, matching how mobile Chromium commits hover. A touch-down hovers the views on its hit branch and unhovers everything else (a touch on blank space clears all); moves and scrolls in between change nothing; when the first finger lifts, each hovered view stays hovered only if the finger is still over it. A window-level cancel is a system interruption, not a release, so it keeps the hover. This replaces the slop-based dismissal, which dropped :hover on any movement even when the finger released back over the view.

Only the first finger drives the touch selectors, matching the web's single active pointer: later fingers are ignored for the whole gesture, a release can arrive as an early pointer-up while other fingers stay down, and a finger that inherits the recycled pointer id mid-gesture cannot re-trigger anything. On iOS, :active/:active-deepest recognizers share a primary-touch token for the same guarantee.

Android keeps the tag-based hit-testing (svg elements included) and the per-host fallback, so the same rules apply inside Modal/Dialog windows; there a cancel drops the hover, since the real release is never delivered.

Verified on an Android emulator and the iOS simulator (release builds): sticky tap, blank-space clear, drag-off release, scroll ending off the view (drops), scroll ending over the view (keeps), svg overlap, and the :active/:active-deepest press cases.