Added delay/backoff for video ingest

[LucasImpulse]

This is to rectify the ingest running into Error 429, it does bring the random and time libraries in to facilitate these delays and the headers are defined to a proper Chrome browser so it's not blocked by YouTube which can be temperamental with that.

Fixes #206

[juananpe]

Thanks for your fix! Looks good to me (and you provided a good explanation) but please, can you apply it against dev branch?

[LucasImpulse]

Thanks for your fix! Looks good to me (and you provided a good explanation) but please, can you apply it against dev branch?

@juananpe Thank you, will do, these things are a first for me :)

[LucasImpulse]

Rebased from main to dev

[juananpe]

@LucasImpulse: Thanks so much for taking the time to work on this and for the detailed implementation. As I said, your backoff/retry logic looks solid and well-thought-out - the exponential backoff with jitter and proper browser headers are exactly the kind of approach that makes sense for rate limiting issues.

However, thanks to your PR after testing it and digging deeper into the root cause of the 429 errors, it turns out this isn't actually a bug we can fix on our end. The issue is specific to YouTube's rate limiting on auto-translated subtitles (e.g., downloading Spanish captions for an English video). According to this yt-dlp issue, YouTube has imposed strict rate limits specifically for translated auto-subs, likely to prevent AI scraping.

The good news is that downloading original language auto-captions (e.g., Spanish captions for a Spanish video) works fine without any 429 errors.

Since this is a YouTube-side limitation rather than something we can solve with retries, I'm going to close this PR.
I’ve opened a new related issue (#219) to add a user-facing warning + handling when requested subtitle language differs from the video's original language. Your implementation skills are solid, and I'd love your help implementing the warning/fallback in that new issue.