fix: use smoothed velocity direction for touch flings to prevent off-axis glides

[JonasGrunau]

Fixes #2225.

What

On touch input, derive the fling direction from the gesture recognizer's velocity (Flutter's VelocityTracker, a least-squares fit over the last ~100 ms of samples) instead of the single last tracked pointer segment. Mouse/trackpad input keeps the tracked-segment behaviour introduced in #2158, which handles the pointer leaving the window mid-drag — a case that cannot occur with touch.

Also negates the velocityDirection passed into flingDirection() as the division-by-zero fallback (#2220), so all three direction candidates share the tracked-offset sign convention (end: flingOffset + direction * distance). Previously the degenerate zero/zero case glided against the swipe, since details.velocity.pixelsPerSecond points along the pointer motion while finalSegment/flingOffset run opposite to it (8.2.2 used the velocity with - direction * distance).

Why

The last tracked segment is one frame-to-frame delta. At fast swipe speeds it is dominated by touch-sampling noise and lift-off thumb-roll, so its direction routinely deviates 30–90° from the swipe axis: fast flicks glide off-axis and repeated flicks visibly zigzag (see #2225 for the full analysis). The fitted velocity direction is stable — it's what the pre-8.3.0 fling used and what platform map apps use.

How

• MapInteractiveViewerState records the device kind of the last pointer-down.
• flingDirection() gains a preferVelocityDirection parameter; when set (touch), the already-normalized velocityDirection is returned directly, otherwise the existing preference order (final segment → overall drag offset → velocity fallback) is unchanged.
• Existing flingDirection tests updated for the new parameter; new test covers the touch preference.

All existing tests pass (flutter test), dart analyze clean, dart format clean.