fix: Require touch slop before DragCallbacks accepts a drag

[spydon]

Description

Since 1.38.0 the MultiDragScaleGestureRecognizer accepted a drag gesture on the very first
PointerMoveEvent in drag-only mode, without checking whether the pointer had actually moved.
Some Android devices emit zero-delta PointerMoveEvents between pointer down and up during a plain
tap, so the drag recognizer won the gesture arena and every TapCallbacks component on the
GameWidget received onTapCancel instead of onTapUp as soon as a single DragCallbacks
component was mounted.

The drag-only path now accepts the gesture only once the accumulated movement exceeds
computeHitSlop, matching the ImmediateMultiDragGestureRecognizer that was used before, and the
pending movement is still delivered as the first drag update.

While writing tests for this, a second cause of cancelled taps showed up: _up and _cancel marked
the pointer state as resolved, so _dispose never rejected the recognizer from the gesture arena.
When the drag recognizer was registered before the tap recognizer (a DragCallbacks component
mounted before any TapCallbacks component), the arena sweep on pointer up picked the drag
recognizer and cancelled the tap even without any move events. The pointer state is now left
unresolved on up and cancel so that _dispose rejects it, the same way Flutter's
MultiDragPointerState does.

Checklist

• I have followed the Contributor Guide when preparing my PR.
• I have updated/added tests for ALL new/updated/fixed functionality.
• I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• [-] I have updated/added relevant examples in examples or docs.

Breaking Change?

• Yes, this PR is a breaking change.
• No, this PR is not a breaking change.

Related Issues

Closes #4016

https://claude.ai/code/session_01EJANnBFMk4Cfh3JRbUboQZ