test(player): drive an engine that answers badly

Fair criticism: hardware time went into writing a checklist describing what the
tablet found, when it should have gone into making the suites able to find it.
A checklist decays and depends on someone following it. A test does not.

The gap was specific. Every engine the conformance suite drives reports sane
numbers, so it stayed green while a real one took the backend down. The old
PlayerBackend contract is a plain f64 — it never promised finite, never
promised positive, and nothing enforced it.

UT-223 adds the engine that was missing: a HostileBackend answering with
C.TIME_UNSET as seconds, NaN, both infinities, a negative and a zero. Reading a
snapshot must yield no duration and a zero position rather than panicking.
Against the adapter as originally written it fails with

    cannot convert float seconds to Duration: value is negative

which is the exact panic that produced a black screen on the tablet — now
reproduced in 0.00s on a laptop instead of by backgrounding an app.

UT-224 pins the other hardware-only finding: stopping clears an active
background-audio handoff, flag and base offset both. That was verified by
listening to a device, which is not a test.

Both were confirmed to fail against the pre-fix code before being kept.

The verification plan now says to prefer moving cases out of it and into tests,
and that what remains should be what genuinely needs eyes, ears or a display —
not what merely has not been automated yet.

793 Rust tests.

docs/native-player-verification.md

@@ -25,8 +25,19 @@ release mechanics. This covers whether the player is fit to release at all.
   a wrong capability for ExoPlayer (DR-246 follow-up) and a `Duration` panic
   (DR-252). Both were invisible to the test suites.
 
-The suites verify engines that behave. **The manual passes exist to catch
-engines that do not.**
+The suites originally verified only engines that *behave*, which is why both
+regressions passed them. That gap is now partly closed in code rather than in
+this document: `UT-223` drives a deliberately hostile engine — `C.TIME_UNSET`,
+NaN, infinities, negatives — through the adapter, and fails with the exact
+panic that produced a black screen on a tablet. `UT-224` pins the handoff
+clearing that was previously verified by listening to a device.
+
+**Prefer moving cases out of this file and into tests.** Anything here that
+could fail automatically should; a checklist depends on someone remembering to
+follow it, and the two defects it was written for cost hardware time that would
+have been better spent making the suites realistic. What is left below is what
+genuinely needs eyes, ears, or a display — not what merely has not been
+automated yet.
 
 ## 1. Automated gates
 

docs/requirements.md

@@ -760,6 +760,8 @@ Internal architecture, components, and application logic.
 | UT-220 | The conformance suite: opening at a position starts there and never at zero, a seek issued while opening is honoured and overrides the start it overtook, pause and play are observable, close is silent and idempotent, and an open cancelled by close never begins playing | DR-242, DR-243 | In Progress |
 | UT-221 | An engine that cannot report a duration does not erase the one the item carries: with the queue holding a 1800s item and the engine answering nothing usable, the controller still reports 1800s | DR-251 | Done |
 | UT-222 | The values that killed the backend are rejected rather than converted: `C.TIME_UNSET` as seconds, negatives, zero, NaN and both infinities all yield no duration, while a real runtime survives | DR-252 | Done |
+| UT-223 | The adapter survives an engine that answers badly. A `HostileBackend` reports `C.TIME_UNSET` as seconds, NaN, both infinities, a negative and a zero; reading a snapshot yields no duration and a zero position rather than panicking, and a well-behaved engine still round-trips. The conformance suite could not have caught this — it only ever drives engines that report sane numbers, which is why it stayed green while a real one took the backend down | DR-252 | Done |
+| UT-224 | Stopping clears an active background-audio handoff, both the flag and the base offset, so a later position read cannot be interpreted against a handoff that no longer exists. Previously verified only by listening to a device | DR-250 | Done |
 
 ### Integration Tests