6.6.2 - The seek window hands the transport intent on

One behaviour fix on the software and audio playback paths, from a field report on 6.5.6. No API change.

Fixed

• A seek no longer discards a transport call that arrives while its reposition is still running. The software and audio hosts park their demux and feeder loops for the duration of a seek by clearing isPlaying, and since 6.1.1 the demuxer reposition that follows is awaited off the main actor (#254). A second seek entering that window therefore read the flag its predecessor had cleared and took it for "was paused".

  A scrub during playback that reaches the engine as two same-target seeks is exactly that shape, and it anchored the audio clock at rate 0 and left the session parked while the engine went on reporting .playing. Only a manual pause plus play recovered it:

  seek#1 programmatic began target=2432.97
  seek#1 programmatic superseded target=2432.97
  seek#2 programmatic began target=2432.97
  [AudioOutput] seekClock to=2432.973 rate=0.0
  

  The intent now lives in a stash that the seek owning the window keeps, whoever supersedes it inherits, and pause() / play() rewrite, and it is read at the landing rather than at entry. That closes two siblings of the same defect along with the reported one: a pause() issued during a reposition was swallowed and playback continued, and a play() issued during one landed at rate 0 under a running loop, freezing exactly like the report.

  The seek finalize no longer reports .playing over a software or audio host that landed paused either. Those hosts carry the durable transport intent now, so it reads their state, the way the native path has since #122. AVPlayer-backed audio keeps the previous default.

  transport call inside the reposition window	6.6.1	6.6.2
  a second same-target seek while playing	clock anchored at rate 0, session parked, .playing	resumes at the target
  pause()	swallowed, playback continued	lands paused, play() resumes from the target
  play() from paused	clock anchored at rate 0 under a running loop	resumes at the target

  Reported by @wunax against 6.5.6 on iOS 26.3 (#292).

Verifying it

aetherctl play --sw --host-calls overlapseek <url> runs the three drills above, each healed to a known state first so one drill's damage is not inherited by the next, and reports PASS, FAIL or INCONCLUSIVE per drill. seektest cannot reach this class at all: it awaits every seek, so its bursts are strictly serial and never interleave.