fix(jellyfin): support Jellyfin 12 authorization

[retardgerman]

Problem

Jellyfin 12.0 disables legacy authorization by default, and a migration turns it off on existing installs as well. AuthorizationContext.cs now gates the old paths behind EnableLegacyAuthorization:

• X-MediaBrowser-Token header — gated, no longer read
• api_key query parameter — gated, no longer read
• Authorization: MediaBrowser … header — always read
• ApiKey query parameter — always read

Anchorr used the first two exclusively, so every Jellyfin request returned 401 after upgrading. Reported as:

error: Request failed with status code 401
    at async routes/jellyfinRoutes.js:87:22

The WebSocket handshake goes through the same AuthorizationContext (WebSocketManager.WebSocketRequestHandler calls _authService.Authenticate), so it was affected too.

Fix

• New shared jellyfinAuthHeaders() helper in api/jellyfin.js emitting Authorization: MediaBrowser Client="Anchorr", …, Token="…". All 11 call sites converted, plus the one in routes/jellyfinRoutes.js. The poller, webhook, seeder, pruner, resolver and weekly roundup all route through api/jellyfin.js and inherit the change.
• WebSocket handshake moved from ?api_key= to ?ApiKey=, with the key URL-encoded. An unencoded key containing & or # could previously truncate or append query parameters.
• Both forms are accepted by 10.10.7 and 12.0, so no version switch is required and older servers keep working.

Hardening picked up while reviewing the change:

• The helper rejects a missing or malformed API key rather than emitting a well-formed header carrying an empty or mangled token. Silently stripping illegal characters would send a different token and surface as an indistinguishable 401. The key is trimmed first, so a value pasted with a trailing newline still works.
• WebSocket auth rejections (401/403 handshake, close code 1008) now log the actual cause instead of looping on reconnect with a generic transport error.
• Raw axios errors are no longer passed to the logger on the Jellyfin paths. The serialized error includes config.headers, which wrote the Authorization header to logs/ in cleartext. This predates the change (it leaked X-MediaBrowser-Token the same way) but is fixed here since this PR introduces the new header. Affected: routes/jellyfinRoutes.js (2x), jellyfinPoller.js.

Verification

• Outgoing request captured against a local HTTP server: the Authorization header is emitted correctly and no X-MediaBrowser-Token is sent.
• Helper edge cases exercised: empty, undefined, whitespace-padded, quote, comma, backslash, NUL, tab, DEL, CRLF.
• Confirmed a token no longer reaches logs/ after the logger change.

Not tested against a live Jellyfin 12 instance.

Out of scope

• The reconnect loop still retries indefinitely on auth failures; it only logs the cause now.
• The silent CollectionId fallback in fetchLibraries can route items to the wrong Discord channel when Jellyfin rejects /Items. Pre-existing, worth its own issue.
• The logger.error("...", err) pattern exists at roughly 20 other call sites. Only the Jellyfin paths were touched, since only those carry an auth header.