feat: bounded retry for a dropped tap, and poll the screen more gently

Running spotify_play against the real phone showed a tap can be delivered
to the app and then never acted on (the dispatcher lists the Spotify window
as the touch target, and the screen does not move). The run log also showed
step durations were printed as 0s while the recorded ones were correct.

- wait steps accept "retry N": on timeout, re-run the step above and wait
  again, up to N extra times. Only a wait may use it, it needs a step above
  it, and it can only press something already matched by text. spotify_play
  uses it on the search box and on the playback check.
- The success log line printed the duration before the deferred assignment
  ran. It now records the duration first.
- uiautomator dump starts a JVM on the phone, and the wait helpers polled
  every 400ms. ui.PollInterval is now 1500ms, which cuts that load on a
  phone that is already short of memory.

docs/phase-3-spotify-recipe.md logs attempts 7-10: the recipe now reaches
tap_row and picks "Honky Tonk Women" at (540,878), but the app stops acting
on input on this loaded phone, so the end-to-end run is still outstanding.

recipes/spotify_play.recipe

@@ -19,7 +19,7 @@ param: query
 row_id: com.spotify.music:id/row_root
 
 step_timeout: 20s
-total_timeout: 150s
+total_timeout: 420s
 
 # Screens Artemis must never tap on. Each one fails the run with the reason, so
 # a wrong tap is impossible (FR-8).
@@ -36,14 +36,16 @@ steps:
   #    no-op, so this is safe to repeat.
   - launch
   - foreground 30s
-  - wait "Search" 30s
+  - wait "Search" 30s retry 2
 
   # 2. Open the search tab. Spotify remembers the last tab, so a search screen
   #    with the previous query can come back: clear that box only when the
   #    clear button is actually on screen.
   - tap "Search"
   - tap_if "Clear search query"
-  - wait "What do you want to listen to?" 30s
+  # retry: the clear tap above can be dropped while the phone is busy, so press
+  # it again before giving up on the empty search box.
+  - wait "What do you want to listen to?" 30s retry 3
   - tap "What do you want to listen to?"
 
   # 3. Type the query. The clear button proves the text landed.
@@ -54,11 +56,20 @@ steps:
   #    never match something from the history instead of a search result.
   - wait_gone "Recents" 30s
 
-  # 5. Play the result that matches the query. tap_row scores every visible
+  # 5. Give the app a moment. Spotify renders the results list after the query
+  #    lands, and the tap below must land on the settled list.
+  - sleep 1s
+
+  # 6. Play the result that matches the query. tap_row scores every visible
   #    result row against the query words and taps the best one; equal matches
   #    go to the highest row, which is how Spotify ranks them.
   - tap_row "{query}" 40s
 
-  # 6. Playback started when the transport button says "Pause". Exact match, so
+  # 7. Playback started when the transport button says "Pause". Exact match, so
   #    Spotify's "Paused" labels do not count.
-  - wait exact "Pause" 40s
+  #
+  #    This is the phone's slowest moment: the app is rendering a new list and
+  #    can stop answering input for a while, so a tap can be dropped. "retry 3"
+  #    presses the row again and waits, up to three more times. It never taps
+  #    anything it did not match by text.
+  - wait exact "Pause" 45s retry 3