Download anything that joins the queue, straight away

Peter asked for it, and it is what makes the YouTube fix comfortable: those
episodes have to be fetched before they play at all, so having them already on
disk by the time he taps Play turns a thirty-second wait into none.

The notification lives on QueueRepository rather than at each call site because
the queue is the one choke point every route goes through -- a rule, a drip
release, a tap on Play, the share sheet, a drag. It reports only ids that were
not in the queue a moment ago, so reordering, removing and advancing say
nothing, and re-adding something already queued (which moves it) says nothing
either.

QueuedDownloads decides what actually needs fetching. Skipping what is already
downloaded or already in flight is the part worth testing: a second download of
bytes on disk costs real data for nothing. A FAILED episode is deliberately
retried, since re-queueing something is a reasonable way to ask for that.

The one-off job carries no network constraint, per Peter's choice that this
happens immediately on any network. The periodic sweep keeps its wifi
constraint. Worth being clear about the implication he accepted: a rule that
catches several episodes at once will now pull them over mobile data, capped
only by DownloadDrainer's ten per run.

Verified on a device: queueing an episode from the episode screen took it from
NONE to DOWNLOADING within seconds and to DOWNLOADED with a file on disk,
rather than waiting for the two-hourly wifi job.

No permission changes, no schema change. 403 unit tests green, detekt and lint
clean, coverage 65.16 -> 65.22.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B

0 files changed, 0 insertions, 0 deletions