feat: Phase 5 — maps_navigate, and read the screen before the input

The Maps recipe: open the search box, type the place, and confirm the
result list names it. Every label comes from a live uiautomator dump
(search_omnibox_text_box, typed_suggest_container, the account sheet),
never from a guess. Text only, one step_timeout/total_timeout, guards for
the account sheet.

The first live run exposed an ordering bug in expect_change. A dump is not
instant, so a baseline taken after the input already showed the app's
response and the check could never see a wedge; it failed against a
healthy Maps. The engine now reads the screen before the step above runs
and hands that signature to the check. Each retry re-reads it.

Live: maps_navigate ok in 27.6s, result list names "Melbourne Museum".
The wedge reason and its bounded retry are demonstrated with a probe
recipe whose input changes nothing; a real wedge could not be forced, and
docs/phase-5-maps-recipe.md says so plainly.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

internal/recipe/recipe.go

@@ -40,8 +40,9 @@
 //     title matches the text; with no text, wait for PLAYING
 //     alone (a radio plays a different track every few minutes)
 //   - wait_gone "Recents" 30s wait until no element matches the text
-//   - expect_change 10s       fail unless the screen changes within the time
-//     (the wedged-app check: a delivered input that the app never acts on)
+//   - expect_change 10s       the screen is read before the step above, so this
+//     fails with "the app stopped consuming input" when
+//     that step's input left the screen unchanged (a wedged app)
 //   - tap    "Search"         tap the element whose text matches (FR-4)
 //   - tap    exact "Pause"    tap an element whose text matches exactly
 //   - tap_if "Clear search query"  tap it when it is on screen, else skip