fix: address the Maps search box by id, and re-prove Phase 5

The Maps omnibox hint rotates: it read "Search here" in the Phase 5 run and
"Try petrol stations, ATMs" in the AUD-128 re-verification, so the recipe's
text match on it failed. The resource id does not rotate.

- internal/ui: add Find/FindID and the "id:" selector; Find dispatches an
  id: selector to the resource id and everything else to text as before.
- internal/recipe: wait/tap/wait_gone/tap_if and the tap helper use Find, so a
  recipe may name a resource id. Guards stay text-only.
- recipes/maps_navigate.recipe: wait/tap id:search_omnibox_text_box.
- tests for the id selector; docs and README updated.

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

recipes/maps_navigate.recipe

@@ -30,11 +30,15 @@ steps:
   - 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"
+  # 2. Open the search box. The box is the EditText with resource id
+  #    "search_omnibox_text_box". It is addressed by id, not by its label,
+  #    because its label is a rotating hint: it reads "Search here" one day and
+  #    "Try petrol stations, ATMs" the next, so a text match here broke in a
+  #    re-verification run. The resource id is stable, and it is still a named
+  #    match rather than a coordinate (FR-4). Tapping it opens the search screen
+  #    with the box focused and a suggestions list below it.
+  - wait id:search_omnibox_text_box 30s retry 2
+  - tap id:search_omnibox_text_box
 
   # 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: