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>

recipes/maps_navigate.recipe

@@ -0,0 +1,58 @@
+# maps_navigate — search Google Maps for a place.
+#
+# Edit this file by hand. Steps name the text Artemis must find on screen; it
+# taps the centre of the element it matched. There are no coordinates here on
+# purpose, so this recipe survives a Maps redesign (FR-4).
+#
+# Run it with:
+#   artemis run maps_navigate query="Melbourne Museum"
+
+task: maps_navigate
+description: Search Google Maps for a place and show the matching result list.
+app: com.google.android.apps.maps
+
+# The caller must supply these.
+param: query
+
+step_timeout: 20s
+total_timeout: 180s
+
+# Screens Artemis must never tap on. Each one fails the run with the reason, so
+# a wrong tap is impossible (FR-8). Maps on this phone is signed in, so the only
+# screen that can get in the way of the search box is the account and settings
+# sheet (labels taken from a live dump of that sheet).
+guard "Manage your Google Account" => Maps is showing its account sheet; press back on the phone and retry
+guard "Turn on Incognito mode"     => Maps is showing its account sheet; press back on the phone and retry
+
+steps:
+  # 1. Make sure Maps is up. Launching an app that is already open is a no-op,
+  #    so this is safe to repeat.
+  - launch
+  - foreground 30s
+
+  # 2. Open the search box. On the map, the box is the EditText labelled
+  #    "Search here" (resource id search_omnibox_text_box); tapping it opens the
+  #    search screen with the box focused and a suggestions list below it.
+  - wait "Search here" 30s retry 2
+  - tap "Search here"
+
+  # 3. The search screen is a new screen, and the wedge check sits here. If the
+  #    tap was delivered but Maps never acted on it, the screen does not change:
+  #    expect_change waits a bounded time, then fails with the distinct reason
+  #    "the app stopped consuming input". "retry 2" presses the tap again first,
+  #    because a dropped tap is more common than a wedged app.
+  - expect_change 15s retry 2
+
+  # 4. Type the place name into the focused box. The suggestions list redraws
+  #    underneath it.
+  - type "{query}"
+
+  # 5. Same wedge check for the typing: a wedged app draws its old screen, so
+  #    the box keeps the old text and this fails on its own reason.
+  - expect_change 15s retry 2
+
+  # 6. The result list must name the place the caller asked for. The first
+  #    suggestion row for the query carries the place as its title and as the
+  #    label of its own row button ("Activate to enter suggestion <place> into
+  #    search bar"), so a match here is a real suggestion row, not an empty box.
+  - wait "{query}" 30s else "the Maps result list did not name the place"