5.0.3

Bugfix release.

Fixed

A seek issued while paused no longer re-engages playback (#122)

With playback paused by the host (declared .paused, underlying player rate=0), a skip or a scrub commit spontaneously resumed the underlying player (rate=1, timeControlStatus=playing) with no host play() call.

Root cause: the normal seek finalize set state = .playing regardless of the transport intent in effect when the seek was issued. That both reported playing after a paused scrub and weaponised the #93 stall-recovery reassert. The seek's own paused landing (timeControlStatus == .paused), arriving while state == .playing inside an open recovery window (a backward skip's rebuffer opens one), was misread as a spurious pause, so the engine called host.play().

Fix: the finalize now derives its state from the durable transport intent (the native host's playIntent, which a seek never touches). A paused scrub lands paused and presents the new frame, and engineStateIsPlaying stays honest so the stall-recovery reassert only fires on genuine stalls. A playing scrub is unchanged; non-native hosts keep the prior .playing default (they carry no durable transport intent and are unaffected).

Thanks to rrgomes for the traces isolating the three trigger points (seek finalization, target declaration, post-storm settle) and confirming that a plain pause with no seek in flight is never affected.

Verification

552 tests pass, strict-concurrency (-strict-concurrency=complete) clean, tvOS-simulator build succeeds.

Full changelog: 5.0.2...5.0.3