Fix #223: URI encode links

[XanderLuciano]

Closes #223. Originally surfaced via the downstream consumer rdt-client#962.

Problem

Request.cs passes the raw address string straight to Uri.TryCreate:

if (Uri.TryCreate(address, UriKind.Absolute, out Uri uri) == false)
{
    uri = new Uri(new Uri("<http://localhost>"), address);
}

Per RFC 3986, square brackets are reserved for IPv6 literals in the host component only; [, ], {, }, and unencoded spaces are illegal in a path segment and must be percent-encoded. .NET's URI parser is platform-sensitive here:

• Windows silently tolerates and auto-encodes these characters, hiding the bug.
• Linux (.NET 8 / 9 / 10) is stricter — TryCreate either returns false (falling through to the http://localhost base-URI branch and producing a 404) or yields a Uri that HttpClient transmits incorrectly.

Real-world triggers are Debrid download links (Real-Debrid, TorBox, AllDebrid) that embed the torrent filename, e.g.:

https://real-debrid.com/d/ABCDEF/[SubGroup] Series - 03 [1080p WEB-DL].mkv

Fix

Added UrlHelper.EnsurePathEncoded(string) in src/Downloader/Extensions/UrlHelper.cs. It:

• Operates only on the path. Scheme, userinfo, host (including IPv6 literal brackets like [::1]), port, query, and fragment are preserved byte-for-byte.
• Uses the RFC 3986 pchar safe set — alphanumerics plus -._~!$&'()*+,;=:@. Everything else in a segment is percent-encoded as UTF-8. This matches the behavior of Go's net/url.PathEscape, Python's urllib.parse.quote, and Node's WHATWG URL, so downloads now send the same request line curl or a browser would.
• Is idempotent. Existing valid %XX triplets pass through unchanged (lowercase hex is normalized to uppercase). Safe on already-encoded or partially-encoded input.
• Decomposes the URL manually rather than via Uri, because Uri is exactly what rejects these URLs on Linux.

Wired in at every ingestion point where a server- or user-supplied URL string reaches new Uri():

File	Line	Site
Request.cs	49	Primary entry — every download URL flows here via AbstractDownloadService.InitialDownloader
SocketClient.cs	203	HTTP 30x redirect — server-supplied Location header
SocketClient.cs	143	Referer header

No public API changes. UrlHelper is internal.

Why a helper, not an inline fix?

Three call sites, subtle correctness requirements (idempotency, IPv6-host preservation, pchar set). Centralizing gives one well-tested implementation rather than three near-duplicates.

Tests

Added UrlHelperTest.cs with 26 [Theory] cases plus 3 [Fact] checks:

• Motivating bug: [SubGroup] ... [1080p].mkv → correctly encoded
• Curly braces, unencoded spaces
• Pipe, caret, backtick, double-quote, angle brackets (all illegal in path)
• Query string preserved verbatim even when it contains [ ]
• Fragment preserved verbatim
• IPv6 literal host ([::1], [2001:db8::1]) left untouched — only path encoded
• Userinfo (user:pass@host) preserved
• RFC 3986 sub-delims and : @ preserved in path (not over-encoded)
• file:// scheme works the same way
• Already-encoded URLs pass through unchanged (idempotency, 6 sample URLs × 2 passes)
• Lowercase hex triplets normalized to uppercase
• Standalone % (not followed by two hex digits) encoded to %25
• Authority-only URLs with ? or # but no path — unchanged
• Unicode filenames (Arabic) — UTF-8 percent-encoded, round-trips correctly via Uri.UnescapeDataString
• Request constructor integration: bracketed Debrid URL now yields correct Host and AbsoluteUri

Risk / compatibility

• Windows: Uri previously encoded many of these characters internally anyway; normalizing one step earlier produces identical wire output. No observable regression.
• Linux: the failing URLs now succeed. That is the fix.
• Already-encoded input: idempotency guarantees no double-encoding.
• Serialized DownloadPackage.Urls: these come from req.Address.OriginalString. After this change that's the normalized form. Resuming a package feeds the URL back through Request → idempotent → identical Address. No migration needed.
• Public API: unchanged.