chore(release): v0.12.2

Two download fixes since v0.12.1: transfers longer than five minutes were
being cut off by a total request deadline and restarted from zero, and the
progress bar read "0%" for the whole of a transcode download.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/defect-windows.md

@@ -17,8 +17,8 @@ row can be re-checked or disputed:
 
 ## Present since the first release
 
-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.
+Eighteen defects date to the initial proof of concept (v0.0.1, 2026-06-23) and
+shipped for between two weeks and three 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.
 
@@ -47,6 +47,14 @@ for ~2.
 | 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 |
+| Download client used a 5-minute *total* request deadline, so any transfer longer than that was cut off and retried (DR-289) | v0.0.1 | **v0.12.2** | ~13 weeks | pickaxe |
+| Progress reported 0.0 for any response without `Content-Length` — every transcode download (DR-290) | v0.0.1 | **v0.12.2** | ~13 weeks | absence |
+
+The two v0.12.2 rows are the same latent shape as the `Range` header above:
+the deadline was inert while every download was a short direct copy, and
+became fatal only once DR-171 (v0.5.3) started re-encoding audio for offline
+playback — a transcode is both slow enough to exceed five minutes and
+impossible to resume. Defective for ~13 weeks, hittable for ~5.
 
 ### Why they took so long to surface