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`.

docs/feedback/FB-11-route-planner-tiles-still-blank.md

@@ -247,3 +247,25 @@ this change (no new issues introduced; the new constructor parameter needed its
 in `telemetry_uploader.dart`, to avoid adding a 5th). `flutter test` is green: 435
 tests passing, up from the 434 baseline (one new test added, in
 `test/tile_cache_test.dart`).
+
+### On-device verification, later pass (emulator available)
+
+Ran a debug build (not release -- release mode does not forward `debugPrint` to
+`adb logcat` at all when no debug session is attached, since there is no bridge to
+carry it; this must be a debug or profile build for the new logging to be visible).
+Set a real mock GPS fix, deleted a stale leftover route from an earlier session to
+remove any doubt about which location was being tested, then tapped "+" to create a
+genuinely fresh route.
+
+**The blank-map bug is confirmed fixed.** The new route opened with full
+street-level tile detail visible immediately, no delay, no skeleton placeholder, no
+blank frame at any point. Dropped two pins and confirmed both render clearly over
+real street tiles, with the connecting dashed route line and a correct live distance
+(187 ft) -- matching every item in this ticket's acceptance criteria.
+
+Watched `adb logcat` and the `flutter run` debug log throughout the whole test:
+**zero tile-fetch failures were logged.** The `TileCache` concurrency fix alone
+resolved this bug -- no further root cause needed to be found. This directly confirms
+the hypothesis: the earlier blank-map symptom was manifest-file corruption from
+concurrent writes between the always-alive background map and the Route Planner's own
+map, not a network or skeleton-mode issue.