Download manager: cancel/retry/queue controls + dedup off-switch

Download management UI (web + desktop):
- Cancel a running job (SIGKILL, marked "cancelled" so it isn't auto-retried
  and shows a distinct state rather than a misleading error class)
- Cancel a still-queued job before it starts
- Manually retry a failed/cancelled job (fresh auto-retry budget)
- Live speed · ETA · % on running jobs, parsed from the yt-dlp progress line
- Expandable full per-job log fetched on demand
New endpoints: POST /api/jobs/:idx/{cancel,retry}, GET /api/jobs/:idx/log,
DELETE /api/queued/:idx.

Perceptual-dedup off-switch:
- backup.dedup_enabled (default true) hard-disables the "similar content"
  scan in both UIs; the web scan endpoint returns {disabled:true} and the
  desktop scan no-ops with a note. Wired through all five settings touchpoints.

Docs: README seeking note + ROADMAP recently-shipped updates for the prior
seekable-playback / federation / auto-tagging work.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

README.md

@@ -359,10 +359,12 @@ switch to **Bundled** in Settings.
 **Web UI says "authentication required" but no password is set**
 Sessions cleared after the password was changed. Refresh the page.
 
-**Videos play but seeking jumps to the start**
-That's the transcoding mode (`web.transcode = true`). MKV streams can't be
-seeked while transcoding live; turn it off if your browser can play MKV
-directly.
+**Videos play but seeking is approximate**
+That's usually transcoding mode (`web.transcode = true`). yt-offline can
+scrub those live ffmpeg streams by re-requesting the stream at a `start=`
+offset, but ffmpeg's fast seek lands on a nearby keyframe rather than an
+exact byte position. Turn transcoding off if your browser can play the
+original file directly and you want native browser seeking.
 
 **Connection-reset / "Recv failure" errors on download**
 The defaults already retry 30× with linear backoff. If they're persistent,