fix(downloads): replace the 5-minute total request deadline with a stall timeout

The download worker built its HTTP client with `Client::timeout(300s)`, which
in reqwest is a total deadline that runs until the response body has finished.
Every transfer longer than five minutes was cut off mid-body as "error
decoding response body" and retried. A transcode ignores `Range`, so each
retry restarted from byte zero, met the same deadline, and after three
attempts the download failed — no feature film at transcode speed ever
completed on a device whose audio must be re-encoded, and a large direct copy
limped through in five-minute slices with a backoff between each.

A connect timeout plus a read timeout that resets on every chunk catches a
dead connection without capping how long a healthy transfer may run.

Red first: a loopback server dribbling a body three times longer than the
timeout failed with the old client (and burned the whole retry budget) and
passes now; a second test hangs the socket and shows the stall is still
detected.

DR-289, UT-251.

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

src-tauri/Cargo.toml

@@ -150,6 +150,9 @@ ndk-context = "0.1"
 
 [dev-dependencies]
 tempfile = "3.24.0"
+# `net` for the loopback server in `download::worker::timeout_tests`; reqwest
+# enables it transitively, but a test must not depend on that.
+tokio = { version = "1", features = ["net"] }
 wiremock = "0.6.5"
 
 [features]