shouldRearmWatchdog function
Whether a non-final, progress-less status should re-arm the resume watchdog.
The blanket _cancelResumeWatchdog that runs before every status disarms
the only safety net, so a status that carries no progress and is not final
must put it back or the download can hang unbounded.
enqueued only counts once the task has already been seen PAUSED, and the
native ordering is worth writing down because it is the opposite of what it
looks like. The 9-minute slice emits enqueued -> progress(-5) ->
paused, not the other way round: DownloadTaskRunner AWAITS the
re-enqueue (doEnqueue is suspend, and posts enqueued itself) and only
then returns paused, which the runner's finally posts last. So paused
is the final word and arms the watchdog on its own.
Which leaves enqueued covering the resume-driven case only — and makes
gating it essential rather than cosmetic, because enqueued is ALSO emitted
on the very first enqueue. Arming there would put a 90-second deadline on
every download before it had a chance to start: WorkManager legitimately
holds a job enqueued while offline, in Doze, or behind other work, and iOS
defers a background transfer started while backgrounded. The watchdog does
not merely report — it cancels the task and deletes its resume data. A phone
in a tunnel would lose a multi-gigabyte partial and restart from zero.
Implementation
@visibleForTesting
bool shouldRearmWatchdog(TaskStatus status, {required bool sawPause}) =>
status == TaskStatus.paused || (status == TaskStatus.enqueued && sawPause);