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.

docs/defect-windows.md

@@ -17,11 +17,17 @@ row can be re-checked or disputed:
 
 ## Present since the first release
 
-Fifteen defects date to the initial proof of concept (v0.0.1, 2026-06-23) and
+Sixteen defects date to the initial proof of concept (v0.0.1, 2026-06-23) and
 shipped for between two weeks and two months before anyone hit them.
 That is the dominant pattern here: not regressions, but original assumptions that
 went unexercised until a later feature leaned on them.
 
+DR-265 is the clearest example of the "present since" / "reachable since" gap
+this file warns about: the `!isPlaying` gate has been there since the first
+commit, but nothing paused the document underneath a playing `<video>` until PiP
+started working on the HTML5 path in v0.5.3. Defective for ~9 weeks, hittable
+for ~2.
+
 | Defect | Present since | Fixed in | Shipped broken for | How dated |
 |---|---|---|---|---|
 | `AudioStreamIndex=0` pinned the video stream as the audio track (DR-140) | v0.0.1 | **v0.4.6** | ~7 weeks | pickaxe |
@@ -40,6 +46,7 @@ went unexercised until a later feature leaned on them.
 | Hero banner auto-rotation never restarted after a manual swipe (DR-038) | v0.0.1 | **v0.9.1** | ~8.5 weeks | pickaxe |
 | Audio-track change asked the player to select a track the transcode never carried (DR-258) | v0.0.1 | **v0.11.1** | ~2 months | pickaxe |
 | Subtitle URL missing its `Stream.` route segment, so every fetch 404ed (DR-259) | v0.0.1 | **v0.11.1** | ~2 months | pickaxe |
+| `timeupdate` gated on `!isPlaying`, so a paused activity froze the position (DR-265) | v0.0.1 | **v0.11.5** | ~9 weeks | pickaxe |
 
 ### Why they took so long to surface
 
@@ -86,6 +93,7 @@ silently correct an out-of-range index — which is exactly why it was reported
 | Positions reported as 0 before the first tick, and always 0 for webview media (DR-178/179/180) | v0.5.3 | **v0.5.5** | feature (DR-159's tick boundary) |
 | Length-less handoff transcode left to the player's own load-error retry, which can only restart it (DR-203) | v0.0.16 | **v0.8.2** | feature (the handoff's progressive-mp3 choice) |
 | Recently Added trusted the server to group new tracks — `GroupItems=true` only groups a track whose parent chain resolves a `MusicAlbum`, and older servers ignore it | v0.5.1 | **v0.11.4** | feature (the v0.5.1 fix for the same symptom) |
+| PiP and the background-audio handoff both armable, decided by one `isInPictureInPictureMode` sample (DR-266) | v0.5.3 | **v0.11.5** | feature (PiP on the HTML5 path, beside a toggle that had shipped in v0.0.16) |
 
 Three of these are worth separating out, because the defect is not a mistake in
 the code so much as **plumbing that was built and never connected**: