Add per-download custom request headers; add “Advanced Settings” section to Add Download Sheet

[QZGao]

Closes #49.

Changelist

Add per-download custom request headers under the (NEW) collapsed "Advanced Settings" section.

• Provide a dedicated multiline header editor using one Name: value pair per line.
  • Validate header names against HTTP token characters and reject invalid value controls U+0000–U+001F (except U+0009 (TAB)) and U+007F (DEL).
  • Preserve duplicate header fields and values containing additional colons.
• Store headers directly with each download record, with empty defaults for backward compatibility.

Pass headers to all possible download pipelines, including URLSession requests and aria2's torrent requests.

• Apply headers to direct URLSession requests and reapply them only across same-origin redirects.
• Fetch remote .torrent files with the supplied headers, including same-origin redirect handling and HTTP/empty-response validation.
• Pass headers to aria2 through its per-download header option for torrent trackers and web seeds.

Warn users before sending Cookie or Authorization headers (may be credentials!) to torrent jobs, because broadcasting those to torrent sites may be a dangerous move.

• Add a submit-time warning fallback if the source changes into an aria2 job after the headers were configured.

Explicitly reject custom headers for yt-dlp media downloads.

• Restrict automatic yt-dlp inspection to known media hosts, preventing non-media files from entering the media pipeline.
• Make debounced download persistence cancellation-aware so superseded snapshots do not overwrite newer state.

Verification: Built and tested locally.

[QZGao]

Rationale for settings placement: It would be a big cognitive burden for non-advanced users to see "Request Headers" settings. Therefore, I shelved it under a newly introduced “Advanced Settings” section.

Rationale for warnings: A careful warning would let the users think twice when using custom Request Headers for torrented downloads; they should know that their Cookies/Authorizations (may very well contain real credentials!) in Headers will be broadcasted in this way. Still, we don't really want to actively scan the Headers for credentials, so other than a Cookie/Authorization keyword match, there are no other mechanisms, and no other intrusive messages beside an one-time warning.

[thsnkhn]

thanks for the pr. I'll be reviewing it. there's another big qol pr also in progress. giving that one priority first

[QZGao]

Merge conflicts are resolved.

[QZGao]

Re-merged from the main branch, and also did some code quality cleanups. @thsnkhn now it is ready for your review.