chore(release): v0.11.5

One fix since v0.11.4: a video in a picture-in-picture window no longer drops
to audio-only partway through, replaying from wherever the picture had been
when the window opened.

Two independent faults had to line up for it. The player's position variable is
written only by a requestAnimationFrame loop while playing, and RAF stops for a
document that is not being rendered -- which an Android activity behind a PiP
window is not; the `timeupdate` handler that would have covered the gap had
gated itself on `!isPlaying` since the first commit. And PiP and the
background-audio handoff, nominally alternatives, could both be armed at once,
with a single `isInPictureInPictureMode` sample taken inside onStop() standing
between them.

The frozen position was not confined to the handoff: the seek bar, resume
points and the progress reported to Jellyfin all read the same variable, so all
three stood still for as long as a PiP window was open.

Version stamped with scripts/set-version.sh. defect-windows.md records DR-265
under the present-since/reachable-since gap: defective since v0.0.1, but only
hittable once PiP started working on the HTML5 path in v0.5.3.

CHANGELOG.md

@@ -9,6 +9,29 @@ generated trace matrix lives in [docs/traceability.md](docs/traceability.md).
 For how long each fixed defect had been shipping before it was found, see
 [docs/defect-windows.md](docs/defect-windows.md).
 
+## v0.11.5
+
+### 🐛 Fixes
+
+- **A video in a picture-in-picture window stays a video.** Watching in a PiP
+  window would sometimes drop to audio only, and the audio would pick up from
+  wherever the video had been when the window opened — while the picture itself
+  had carried on well past that. Two faults, both needed to produce it. The
+  player's idea of where it is in the video is kept by a loop that only runs
+  while the app is drawing to the screen, and behind a PiP window it is not:
+  the position quietly stopped advancing the moment the window opened, and the
+  one other source that could have kept it current had been written to switch
+  itself off during playback. Separately, PiP and the "keep the audio playing in
+  the background" toggle are meant to be alternatives, but only the toggle
+  enforced that — the PiP button could still be pressed with both armed, and the
+  single moment-in-time check meant to tell them apart is not always right about
+  whether a window is open. Opening PiP now turns background audio off, the app
+  trusts its own record of the window as well as the system's, and the position
+  keeps advancing whether or not anything is being drawn. The frozen position
+  also affected the seek bar, resume points and watch progress reported to the
+  server for as long as a PiP window was open. (UR-004, UR-040, UR-041 →
+  DR-265, DR-266)
+
 ## v0.11.4
 
 ### 🐛 Fixes