fix(downloads): floor max_concurrent + stable share order (R12 S5 review)

- Floor the effective max_concurrent at 1 on the read path (quota.resolve)
  and in the claim SQL (GREATEST(..., 1)). admin_set_quota already floors on
  write and the sysconfig default's min is 1, but a stray stored 0 (direct DB
  edit) would diverge the two "at limit" checks — the SQL claim-window
  exclusion can't see a user "capped" with zero running jobs, while
  at_concurrency_limit can — reopening the starvation the fairness fix closes.
  Keeping the effective limit >= 1 makes the two checks provably agree.
- shared_with_me now orders by (created_at DESC, id DESC) to match
  list_downloads, so the newly-added 500 cap has a stable boundary among
  same-timestamp shares instead of a non-deterministic one.
- 0062 upgrade loop: rename the unused loop var "table" to "_table"
  (matching the underscore-marked "_col").

Test: a stored max_concurrent=0 flooder no longer wedges the claim loop.

backend/app/worker.py

@@ -199,7 +199,7 @@ def _claim_job() -> int | None:
                       WHERE r.status='running' AND r.user_id IS NOT NULL
                       GROUP BY r.user_id, q.max_concurrent, q.unlimited
                       HAVING COALESCE(q.unlimited, false) = false
-                         AND count(*) >= COALESCE(q.max_concurrent, :dmc)
+                         AND count(*) >= GREATEST(COALESCE(q.max_concurrent, :dmc), 1)
                   )
                 ORDER BY queue_pos, id
                 FOR UPDATE SKIP LOCKED