chore(release): v0.11.4

Three fixes since v0.11.3: Recently Added groups a new album's tracks into one
album card in the client rather than trusting the server's GroupItems; autoplay
crosses a season boundary instead of stopping dead at the last episode; and a
finished episode is no longer offered as its own "up next". Plus the Android
debug applicationId suffix, which the Tauri CLI's Gradle rewrite had been
dropping, so a debug build again installs beside a release one.

Version stamped with scripts/set-version.sh. defect-windows.md records the
Recently Added grouping as the second fix for the same symptom: v0.5.1 sent
GroupItems=true and the server does not always honour it.

CHANGELOG.md

@@ -9,6 +9,54 @@ 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.4
+
+### 🐛 Fixes
+
+- **A newly-added album shows up as one album, not as fourteen songs.**
+  Importing an album filled the whole Recently Added row with that one album,
+  one card per track, burying everything else added that week. The app does ask
+  the server to group new tracks under their album, but the server only manages
+  it for a track whose folder structure actually resolves an album — and older
+  servers ignore the request altogether. The row is now grouped here as well, so
+  what it shows is a property of the app rather than of the server it is talking
+  to: one card per album, opening the album, keeping its artwork and artists, and
+  standing where the first of its tracks stood so the newest is still first.
+  Standalone tracks and movies are unaffected. (UR-024 → JA-016)
+
+- **A binge plays on past the end of a season.** Autoplay only ever looked
+  inside the current season, so the last episode of one was the end of the line:
+  with the screen locked and background audio playing, that is felt as playback
+  simply stopping mid-binge, with no visible player to start it again. It now
+  crosses into the first episode of the next season that has any, skipping empty
+  seasons and never wandering into Specials. A sleep timer set to end-of-episode
+  still stops at the boundary — crossing it is autoplay's decision, not the
+  timer's. (UR-023, UR-040 → DR-263)
+
+- **The episode you just finished is no longer offered as the one to play next.**
+  Watch an episode to the end, press Back, and the season list still ringed that
+  same episode as "Up next" and scrolled to it. Nothing recorded the completion
+  on the device — progress writes saved a position but never marked an episode
+  watched, and cached server data dropped the watched flag on the way in — while
+  the server's own "next up" answer is briefly one report behind and named the
+  episode that had just ended. An episode is now counted as finished either when
+  the server says so or when its position is past the same 95% mark that already
+  disqualifies it from "continue watching", and the server's answer is checked
+  against that before it is accepted. The highlight, the badge, the auto-scroll
+  and which season opens expanded all follow the episode that really is next —
+  and the checkmarks in the season list stay put. (UR-025, UR-062 → DR-264)
+
+### 🛠 Development
+
+- **A debug build installs alongside a release build again.** `bun run
+  android:dev` produced an APK carrying the release application id, so installing
+  it over a real release build failed outright and the obvious way out was to
+  uninstall the release app and lose its data. The Tauri CLI rewrites the debug
+  section of the generated Gradle file to inject its own settings, and that
+  rewrite dropped the suffix that keeps the two apps apart; the suffix has moved
+  somewhere the rewrite does not reach, and the build now asserts the id the APK
+  actually carries rather than assuming it.
+
 ## v0.11.3
 
 ### 🐛 Fixes