Document Phase 6 on-device verification for FB-10/FB-11

docs/feedback/FB-10-map-pan-recenter-race.md

@@ -239,3 +239,25 @@ No Android emulator or `adb` was available in this environment, so the on-device
 check in Implementation step 5 was not attempted here. A later verification pass
 should do that real check; the widget test above is the bar this ticket's own
 acceptance criteria actually rest on.
+
+### On-device verification, later pass (emulator available)
+
+Attempted a real drag on the emulator with `adb shell input swipe`,
+`input touchscreen swipe` (varied distance/duration), and `input draganddrop` — none
+of them moved the camera at all, on either the idle Map tab or during a recording.
+This is the same negative result the FB-06 verification pass hit earlier, before this
+ticket's fix even existed, and taps/scrolls elsewhere in the exact same build worked
+correctly throughout this same session (Settings list scroll, tab switches, pin
+drops in Route Planner). This points at an `adb`-synthetic-gesture limitation against
+`flutter_map`'s own drag recognizer specifically, not a working/not-working signal
+for this ticket's fix — `adb`'s injected swipes plausibly don't carry the
+intermediate pointer-move samples `flutter_map`'s pan recognizer needs to arm,
+regardless of what `_gestureInProgress` is doing underneath.
+
+Given the widget test added by this ticket reproduces the actual race with a real
+`tester.startGesture`-driven pointer (not a synthetic `hasGesture` callback) and
+passes only with the fix applied, and given the code review confirms the fix matches
+the ticket's Design section exactly, this is treated as verified via the test suite.
+A real human touch on a physical device or the emulator's own window (not `adb
+input`) is the only way left to add further confidence here, and should still happen
+opportunistically rather than being chased further through `adb`.