feat: detect a wedged app with expect_change

An app can stop consuming input while it keeps drawing: Android delivers
the tap, the app never acts on it. Phase 3 hit this three times against
Spotify and the recipe failed on the label it was waiting for, which names
the wrong problem.

The new `expect_change <duration>` step fingerprints the screen (foreground
package plus every visible label and its bounds) and fails when the screen
does not change after the previous step, with the distinct reason
"the app stopped consuming input". It supports `retry N`, which re-presses
the step above a bounded number of times, so a dropped tap is still
recovered and a wedged app still ends the run (FR-11).

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

README.md

@@ -88,6 +88,10 @@ file format, the verbs, and why list rows need their own step, and
 - **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 "..."`.
+- **Detect a wedged app.** An app can stop consuming input while it keeps
+  drawing: Android delivers the tap, the app never acts on it. `expect_change`
+  fails with `the app stopped consuming input` when the screen does not change
+  after the previous step, instead of blaming the label the next step waited for.
 - **Never touch a locked phone.** A secure keyguard stops Artemis with
   `phone is locked; unlock it and retry`. No PIN is stored, read or typed
   (AGENTS.md section 13 Q2).