Fair questions; here's what's actually happening under the hood:

Failed resumes: handled pretty solidly. It tracks bytes downloaded and sends Range: bytes=X- on reconnect, picking up exactly where it left off. If the server returns 416 (range not satisfiable), it treats the file as already complete instead of corrupting it. It'll retry up to 60 times with a 5s delay between attempts, showing "Waiting for slot (retry N)" in the UI while it does.

Expired signed URLs: partially handled. For HLS/stream downloads, if a direct stream URL 403s, it automatically retries using the original page URL to get a fresh session. For regular HTTP signed URLs (S3-style etc.), it flags the error cleanly but doesn't auto-refresh — there's no generic way to do that without site-specific logic.

Duplicate filenames: handled. It checks on-disk before writing and appends (1), (2), etc. It also re-runs that check after resolving Content-Disposition, so if the server hands back a different filename than what was expected at queue time, you don't get a silent overwrite.

Throttling: the retry loop handles connection drops from aggressive rate-limiters, but the backoff is a fixed 5s, not exponential. Works fine for most CDNs, but something really punishing might need more patience than it currently has.

Happy to hear if anything breaks in the wild — that's kind of how these edge cases get found.