fix: record step durations, and pin the foreground app before matching text

Two defects found by running spotify_play against the real phone.

- Step durations were always zero in the run log: executeStep returned a copy,
  so the deferred assignment never reached the caller (FR-10). It now returns a
  named value, with a regression test.
- The phone was sitting on the Android Settings app, and wait "Search" was
  satisfied by Settings' own "Search Settings" entry, so the recipe tapped the
  Settings search bar. New "foreground" step waits until the recipe's app really
  is in front; spotify_play uses it right after launch.

docs/phase-3-spotify-recipe.md now logs all six live attempts and states
plainly that the end-to-end playback run has not completed: the phone is
showing a Settings "Verify that it's you" biometric prompt, which needs Sam and
is left untouched.

docs/phase-3-spotify-recipe.md

@@ -53,10 +53,13 @@ Run it with:
 ./bin/artemis run spotify_play query="Rolling Stones Honky Tonk"
 ```
 
-The verbs are `launch`, `wait`, `wait_gone`, `tap`, `tap_if`, `tap_row`, `type`,
-`key`, `back`, `home` and `sleep`. `tap exact "Pause"` matches the whole text,
-not a substring. `tap_if` taps only when the text is already on screen, which
-lets one recipe cope with an app that remembers its last screen.
+The verbs are `launch`, `foreground`, `wait`, `wait_gone`, `tap`, `tap_if`,
+`tap_row`, `type`, `key`, `back`, `home` and `sleep`. `tap exact "Pause"`
+matches the whole text, not a substring. `tap_if` taps only when the text is
+already on screen, which lets one recipe cope with an app that remembers its
+last screen. `foreground` waits until the recipe's app is really in front, so a
+word like "Search" cannot be matched from a different app that happens to be
+open — every recipe should use it straight after `launch`.
 
 ## Why `tap_row` exists
 
@@ -185,15 +188,44 @@ keyguard; reading the state first would say "unlocked" about a locked phone.
 | Recipes file format, guards, parameters, timeouts | unit tested (`internal/recipe`) |
 | Row selection against a real Spotify dump | unit tested (`internal/ui`) |
 | Keyguard parsing and secure-lock detection | unit tested (`internal/ui`) |
+| Step durations reach the run log | unit tested (`internal/recipe`) |
 | All acting commands refuse on a locked phone | **live, verified** (above) |
 | `artemis run spotify_play` refuses on a locked phone | **live, verified** (above) |
 | `spotify_play` plays the right song | **not yet run end to end** — see below |
 | Spotify search reaches the result list | live (Home → Search → type → results) |
 
-The live end-to-end run of `spotify_play` (Phase 3 DoD) has not been completed.
-The phone locked itself part-way through the session (5-minute screen timeout,
-secure keyguard) and Artemis will not unlock it by design. It needs a human to
-unlock the phone, and then:
+## Live run log
+
+Six attempts, in order. Each failure was clean, named its screen and tapped
+nothing random — which is the point of the phase.
+
+1. **Refused, locked phone.** `phone is locked; unlock it and retry`. The phone
+   had locked itself on its 5-minute screen timeout while the code was being
+   written.
+2. **Refused after the prescribed sleep/wake test.** `keyguard showing=true
+   secure=true`, exit 1 from `keyguard`, `tap` and `run`. The lock screen was
+   still on screen afterwards.
+3. **Refused, dozing phone that only *looked* unlocked.** A dozing phone reports
+   `showing=false`. Pressing WAKEUP then revealed the secure keyguard, and the
+   run refused. This is why every acting command wakes first.
+4. **Wrong app matched "Search".** The phone was sitting on the Android
+   Settings app. `wait "Search"` was satisfied by Settings' own "Search
+   Settings" list entry, so the recipe tapped the Settings search bar. Fixed by
+   adding the `foreground` step, which waits until the recipe's app really is in
+   front before any text is trusted.
+5. **Blocked by a biometric prompt.** Settings was left showing a
+   `Verify that it's you` dialog (`Touch the fingerprint sensor` / `Use PIN`),
+   which is drawn over Spotify. The run failed with:
+   `text "Search" did not appear within 30s; foreground=com.spotify.music;
+   screen shows: "Cancel", "App logo", "Settings", "Verify that it's you" ...`.
+   Artemis did not touch the prompt, and it must not: it needs Sam's fingerprint
+   or PIN, exactly like the lock screen.
+6. **Still blocked** by the same prompt on the next attempt.
+
+### What is left
+
+The live end-to-end run of `spotify_play` (Phase 3 DoD) has not completed. It
+needs the phone unlocked and free of the biometric prompt, and then:
 
 ```sh
 ./bin/artemis run spotify_play query="Rolling Stones Honky Tonk"