fix(downloads): a suspended user's queued jobs wait, and a clip too big for the space left says so

A suspension now blocks the user's downloads as quota.resolve already advised: the worker leaves
their queued jobs unclaimed until it is lifted (the confirm says so). A cut clip larger than the
remaining storage is refused with its own message (not "storage is full"), and a clip's quota
refusal reads as a clip's in both languages. The cancel poll compares to JobStatus.RUNNING.

backend/app/worker.py

@@ -163,7 +163,11 @@ def _claim_job() -> int | None:
     seen.) The per-user limit is the quota row's `max_concurrent` (else the sysconfig default);
     `unlimited` users are never capped. A final Python `at_concurrency_limit` re-check still guards
     the tiny race between the exclusion subquery and the claim (it can only ever reject, never
-    over-claim), so correctness never depends on the two observations agreeing."""
+    over-claim), so correctness never depends on the two observations agreeing.
+
+    A suspended user's queued jobs are left where they are: suspension blocks their downloads (not
+    only their sign-in), and lifting it lets them run in their old place. A job already running
+    when the user is suspended finishes."""
     with SessionLocal() as db:
         default_mc = sysconfig.get_int(db, "download_default_max_concurrent")
         rows = db.execute(
@@ -171,6 +175,10 @@ def _claim_job() -> int | None:
                 """
                 SELECT id, user_id FROM download_jobs
                 WHERE status='queued'
+                  AND NOT EXISTS (
+                      SELECT 1 FROM users u
+                      WHERE u.id = download_jobs.user_id AND u.is_suspended
+                  )
                   AND NOT EXISTS (
                       SELECT 1 FROM media_assets a
                       WHERE a.id = download_jobs.asset_id AND a.status = 'downloading'