Stop reporting playback on a clip that ended during the play call

[danielchalmers]

PlayAsync sets IsPlaying once its play operation completes, with nothing checking whether the clip is still running by then. A clip that reaches its end while that operation is in flight raises Ended, whose handler clears IsPlaying, and then the play call sets it straight back. The transport is left claiming to play a clip parked on its last frame until you press something else.

Evidence, re-measured on current main

Traced on the real stack (FlyleafLib 3.11.5) with a clip paused just before its end, seeked, and played straight away:

play-enter
+28ms  Flyleaf PlaybackStopped, status Ended   <- the clip finishes inside the play call
+30ms  controller IsPlaying=True               <- the play call then asserts playback
play-return

The Ended handler did run. Its IsPlaying = false just raised nothing, because the value was already false.

	without guard	with guard
seek near the end, play immediately	3/40 wrong	0/80 wrong (two runs)
same, human-paced 300ms gap	0/40	0/80

Rare by hand, since the window is only as long as the play call, and a play call is only slow while Flyleaf still has a seek in flight. The invariant is still wrong, though, and anything that makes play wait on a pending seek widens exactly this window.

A correction

The original description said the window came from "a play queued behind an open still joining secondary cameras, which took eight seconds". That was wrong. Those measurement runs still had the seek-settled gate from the Flyleaf 9.0 work, which waited up to 2s per player in the speed setter, and PlayAsync applies speed to 4 players: 4 × 2s = 8s. The gate was deleted before #74 merged. So the original trace overstated how reachable this is, and the numbers above are the honest ones.

The fix

A counter bumped by the Ended handler lets the play call tell that the clip finished underneath it and leave the settled state alone. FakeCameraPlayer gains a PlayCallback hook, mirroring its existing SeekCallback.

Two tests: one ends the clip from inside the play call and asserts the controller does not report playback, one asserts an ordinary resume still does. Verified the first fails without the guard.

Not in scope

This does not fix pressing play on a clip that has already finished, which can also leave the video frozen while the transport reports playback. That's a separate race between Flyleaf's asynchronous seek and its Play(), and it predates v1.0.0.

Rebased onto 9e2f466. 374 tests green, formatting clean.