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.

README.md

@@ -84,10 +84,12 @@ labels, the `expect_change` check, and the one ordering rule it depends on.
 
 ## Rules that the code enforces
 
-- **Find by text, never fixed coordinates.** `tap` resolves a text match to
+- **Find by text, never fixed coordinates.** `tap` resolves a match to
   bounds and taps the centre; `tap_row` scores result rows against the query
   and taps the winning row's centre; `menu_row` opens the action menu of that
-  same row, from the button inside it.
+  same row, from the button inside it. Where a visible label rotates (the Maps
+  search box), a step names the stable resource id with the `id:` selector —
+  still a named match, still no coordinates.
 - **Never tap blindly.** A missing or disabled element is a loud failure, not a
   guessed coordinate. A named bad screen (`guard`) fails with its own reason,
   and a step may name its own failure with `else "..."`.