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/routes/downloads.py

@@ -385,7 +385,7 @@ def shared_with_me(
             select(DownloadJob)
             .join(DownloadShare, DownloadShare.job_id == DownloadJob.id)
             .where(DownloadShare.to_user_id == user.id)
-            .order_by(DownloadShare.created_at.desc())
+            .order_by(DownloadShare.created_at.desc(), DownloadJob.id.desc())
             .limit(_MAX_LIST)
         )
         .scalars()