Fix cookie-specific Video unavailable fallback

[JT4G]

Summary

Fixes #812.

When Youtarr is configured with cookies, some YouTube videos can fail with Video unavailable even though the same video is available when accessed anonymously.

This adds a targeted fallback for that case: if a download fails with the cookie-specific Video unavailable error, Youtarr automatically retries that video without cookies.

What changed

• Detects the specific Video unavailable failure when cookies are configured.
• Marks only those failures for an anonymous retry.
• Adds --no-cookies to the targeted retry while leaving normal downloads and existing transient 403 retries authenticated.
• Splits mixed retry batches so authenticated and anonymous retries are never sent in the same yt-dlp invocation.
• Preserves the existing auto-retry attempt limit and job/run tracking behaviour.
• Does not retry unrelated Video unavailable failures when cookies are not configured.

Why

I reproduced the issue described in #812: a video that failed in Youtarr while using account cookies could still be downloaded when yt-dlp was run without those cookies.

Another user in the issue also reported that affected videos would not play while logged into the account used for the cookies, but would play from another account. This suggests the failure can be specific to the authenticated account rather than the video actually being unavailable.

Rather than disabling cookies globally, this keeps the normal authenticated behaviour and only falls back to an anonymous extraction for the affected video.

Testing

Added/updated unit coverage for:

• cookie-specific Video unavailable detection
• ensuring the fallback is only enabled when cookies are configured
• preserving authenticated handling for ordinary HTTP 403 retries
• marking cookie-specific retries as anonymous
• splitting mixed authenticated/anonymous retry batches
• verifying --no-cookies is added only to anonymous retries
• existing retry/finalizer expectations

Relevant test suites:

Test Suites: 4 passed, 4 total
Tests:       314 passed, 314 total
Snapshots:   0 total

[BigFlubba]

While I do like this option. I think implementing #774 first, then adding the option to have "Video unavailable" errors added to the list of errors that bypass cookies, would be a better option. This way, the codebase doesn't need to be rewritten twice for both options.

[dialmaster]

I like this approach, but there are some issues before I will merge it:

1. an you retarget this at dev? All contributor PRs go through dev (Git Workflow section in CLAUDE.md). The automatic review and the RC image build only run there, so a merge to main would skip both and go straight to release. The files you touched are identical on dev and main right now, so it should be a clean retarget.
2. The commit needs a conventional prefix (fix: ...). Our release tooling reads those for the changelog, and we merge rather than squash, so the commit itself is what matters, not just the PR title.
3. Your runtime test in #812 was on v1.81.1. Since v1.82.1 we add --extractor-args youtube:player_client=default,mweb,web_safari whenever a cookies file is configured (the SABR 360p workaround from #799), and that still gets added on the anonymous retry because the merge keys off config, not the args. So the retry now runs --no-cookies plus those clients, which nobody has actually run yet. Can you re-test on a current build (dev-latest is fine) and confirm the video still comes through? I left an inline note on this.
4. Docs and UI text: the transient403RetryPlanner blurb in CLAUDE.md, the downloadAutoRetryCount entry in docs/CONFIG.md, and the helper text in DownloadPerformanceSection.tsx (plus its test) all say the auto-retry is 403-only. Since that setting now caps the cookie fallback too (and 0 turns it off), please update all three, plus the JSDoc on enqueueAutoRetryJob.

The rest of my comments are inline.

Regarding the other comment about #774, I don't think we need to block on it. #774 is basically the mirror image (anonymous first, cookies on failure), and the plumbing here is what it'd reuse with the flag flipped.

[BigFlubba]

Regarding the other comment about #774, I don't think we need to block on it. #774 is basically the mirror image (anonymous first, cookies on failure), and the plumbing here is what it'd reuse with the flag flipped.

I like that wording better than what I had in my head. Even though it will take a little longer, it is still a better approach if the user opts into it because (combined with a VPN that has a shared IP) it reduces what Google knows about you specifically and the chance of getting blocked. PO support will also add to that because, even with cookies, I am getting limited and blocked in some areas. Gotta love it.

[dialmaster]

Remaining issues to address after your last round of changes:

1. The PR still targets main. Retarget to dev
2. The commit still needs the fix: prefix.
3. Text that still says the auto-retry is 403-only:

• the transient403RetryPlanner blurb in CLAUDE.md
• the downloadAutoRetryCount entry in docs/CONFIG.md
• the helper text in DownloadPerformanceSection.tsx and its test
• the enqueueAutoRetryJob JSDoc
• the "transient 403 failures" log lines in downloadModule.js and the finalizer
• the job label (autoRetryJobLabel(count, { anonymous }) with a (no cookies) suffix is fine)
• the PR description, which still says the retry adds --no-cookies
  4.The $ anchor: the regex on this push is the same as the original, so nothing changed there. I'm fine keeping the anchor (a sub-reason like "This video is private" is a real unavailability and an anonymous retry won't help), but say that in a comment and add a test showing the sub-reason form doesn't match.

5. The new executor test uses a literal \\n in its fixtures instead of \n like the 403 test right above it, so the error never matches the pattern and the test passes even if you flip the directive to cookiesEnabled: true. Fix the fixtures and add a positive case there and in the finalizer suite that asserts enqueueAutoRetry gets anonymousRetry: true. Right now the positive path has no test at any level.
6. isCookieVideoUnavailableFailure still runs twice per video.

And finally: Now that the anonymous run reports cookiesEnabled=false, a bot check or 403 on that run tells the user to "set cookies in your Configuration", which is wrong for someone who has cookies. It probably needs a third message ("anonymous fallback also failed" or similar) in the finalizer and the output router.