fix(maintenance): download queue needs a sweep threshold above its 25-min time_limit

recover_stalled_task_runs used the 5-min default for the download queue,
but download_source legitimately walks up to DOWNLOAD_HARD_TIME_LIMIT
(1500s = 25m). Healthy in-flight Patreon/gallery-dl walks were flagged as
phantom 'RecoverySweep' failures — visible in System Activity but absent
from the Subscriptions view (the download finished ok, reset the source's
consecutive_failures; only the orphaned task_run kept the stamp, since
_finalize only updates rows still 'running').

Add download:30 to QUEUE_STUCK_THRESHOLD_MINUTES — clears the 25-min hard
limit with buffer and matches DOWNLOAD_STALL_THRESHOLD_MINUTES so a real
hard kill is swept by the task-run and event sweeps together. Restores the
documented invariant (every override >= task time_limit). Regression test
pins the threshold above the hard limit so a future limit bump can't
silently re-break it.

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

backend/app/tasks/maintenance.py

@@ -120,6 +120,15 @@ IMPORT_BATCH_KEEP_DAYS = 30
 #   files); time_limit=2100.
 QUEUE_STUCK_THRESHOLD_MINUTES: dict[str, int] = {
     "ml": 25,
+    # download_source legitimately walks 5-25 min (Patreon/gallery-dl
+    # deep creators); its hard time_limit is DOWNLOAD_HARD_TIME_LIMIT
+    # (1500s = 25m). The 5-min default flagged healthy in-flight walks as
+    # phantom 'RecoverySweep' failures (System Activity showed errors the
+    # Subscriptions view correctly didn't — the download finished ok and
+    # reset the source). 30 clears the 25-min limit with buffer and lines
+    # up with DOWNLOAD_STALL_THRESHOLD_MINUTES (30) so a genuine hard kill
+    # is swept by the task-run AND event sweeps together. Audit 2026-06-10.
+    "download": 30,
     # Audit 2026-06-02 — maintenance/scan queues run tasks that
     # legitimately exceed the 5-min default (verify_integrity at 70m
     # hard, scan_directory at 70m hard, apply_allowlist_tags /