fix(downloads): Retry and Re-download take a cookie added after the failure

The login-wall copy tells the user to add their cookies and press Retry, but
Retry kept the job on the shared asset the worker never attaches a cookie to,
so it failed on the same wall. Resume now moves a pending/errored job onto the
asset enqueue would pick with the cookie (never off a file or a download in
flight).

Re-download salted its fresh asset with the job's previous asset id, which the
cookie gate cannot recompute, so even a cookie download rebuilt without the
cookie. The rebuild salt is now the new asset's own id (plus the user's cookie
salt when one applies), and is_authed_asset recognises it.

backend/app/routes/downloads.py

@@ -630,8 +630,9 @@ def redownload_download(
     resolves to the newly-downloaded file — a re-download never breaks a link you already sent out
     (only a *failed* re-download leaves the job in `error`, which is the intended broken-link case).
 
-    The rebuild always re-fetches into a FRESH, private asset (the cache sig is salted with the job
-    id + current asset id) rather than the dedup pool. That means it (a) always genuinely rebuilds
+    The rebuild always re-fetches into a FRESH, private asset (the cache sig is salted with the new
+    asset's own id, and the user's cookie salt when one applies — `credentials.rebuild_salt`) rather
+    than the dedup pool. That means it (a) always genuinely rebuilds
     under the current format/naming rules — never silently reuses a shared cached file — and (b)
     never deletes a file another job/user still shares: the old asset is only removed if THIS job
     was its last holder."""