link: transient and unknown provider codes must not be cached as permanent

[radamhub]

📌 Description

• One transient provider error makes a file unreadable for the rest of the process lifetime, because the failure is cached and only a restart clears it. This is the mechanism behind "playback works, then stops until I restart the container".

Reported in #179.

---

Target Branch Check (IMPORTANT)

• I confirm this PR is targeting the correct branch

Expected target:

• beta (for features)

---

Changes Made

In ErrorCodeToLinkError (pkg/manager/link/errors.go):

• 429 and 503: CategoryRetryable → CategoryRefetchable. On the link-validation path only ShouldDisableAccount() and ShouldRefetch() are consulted, and CategoryRetryable is acted on by neither, so the error falls through and the failure is memoised against the download URL. When a provider derives that URL deterministically the cache key never rotates, which makes a rate limit exactly as permanent as a hard failure.
• Added 500, 502, 504 as Refetchable for the same reason.
• default: CategoryPermanent → CategoryRefetchable. An unrecognised code is not evidence of permanent failure, and CategoryPermanent means neither retry nor refetch, so a single transient 400 poisons the file until the process restarts.
• Genuinely permanent codes are unchanged: 401/unauthorized, 404, link_not_found, file_not_available, and the account/quota codes.
• Added pkg/manager/link/errors_category_test.go asserting both directions.

Refetchable is the right category here because it is the only one that drops the memoised entry and returns a fresh link, and it does so without re-validating, so it cannot loop.

---

Testing

• Tested locally

Steps:

1. go test ./pkg/manager/link/ -run TestTransientCodesAreRefetchable -v passes with the change. Without it, 400 and unknown codes are reported permanent and 429/503 do not refetch.
2. Ran the patched build for several days on a ~4000-file TorBox library. Before the change, a single transient 502 during validation left files unreadable while the very same HEAD request returned 200 when retried by hand. I reproduced that three times. After the change, those files recover on their own without restarting the container.
3. Verified the permanent codes still terminate immediately: a real 404 is not retried in a loop.

---

Risks / Notes

• Broadens what gets a second chance, so a genuinely dead link now costs one extra refetch before failing. That refetch does not re-validate, so there is no loop and no added latency on the happy path.
• Behaviour for permanent codes is unchanged, which the test pins down explicitly to guard against over-correcting.
• No config, API or on-disk format changes.
• Independent of the streaming PR (different package, different code path); order does not matter, though the streaming one is the smaller review.

---

Checklist

• Code builds successfully
• No console/log errors
• Reviewed my own code
• Target branch is correct