fix Jellyseerr avatars for locally-created users (400 from proxy/avatar)

[Kisnov]

Description

Requests made by locally-created Jellyseerr users (accounts made inside Jellyseerr with email + password, not linked to a Jellyfin account) never show an avatar, and every render of the Requests page fires a failed request:

GET /JellyfinEnhanced/proxy/avatar?path=https%3A%2F%2Fgravatar.com%2Favatar%2F<md5>%3Fdefault%3Dmm%26size%3D200 400 (Bad Request)
    at resolveProtectedAvatarUrl (helpers.js:80)
    at hydrateAvatarImages (helpers.js:88)
    at renderPage (requests-page-render.js:310)

with ProxyAvatar: unsafe characters in path blocked on the server side.

Root cause

Jellyseerr stores two different shapes in user.avatar:

user type	avatar value	source
authenticated via Jellyfin/Emby	/avatarproxy/<jellyfinUserId>?v=<n> (relative)	server/routes/auth.ts:232, server/routes/user/index.ts:788
created locally in Jellyseerr	https://gravatar.com/avatar/<md5>?default=mm&size=200 (absolute)	server/routes/user/index.ts:197

JellyfinEnhancedController.cs:9046 wrapped both in the proxy unconditionally, but ProxyAvatar deliberately rejects anything containing :// (line 10174) and then requires the path to start with /avatar/, /avatarproxy/ or /api/v1/avatar/ (line 10185). Both guards are correct as SSRF protection — the bug is that absolute URLs were being sent into an endpoint that only accepts relative ones.

The fix

Absolute HTTPS avatar URLs are passed to the client untouched; relative paths keep going through the proxy exactly as before. This is safe on the client side because:

• <img src> needs no CORS, so the "avoid CORS" reason for proxying doesn't apply;
• HTTPS rules out the mixed-content case;
• resolveProtectedAvatarUrl (js/enhanced/helpers.js:63) already returns any non-proxy URL as-is, and isSafeAvatarUrl already validates the scheme — so no client change is needed.

Non-HTTPS absolute URLs still take the old path (and still 400), which is unchanged behaviour rather than a new regression.

Alternative considered

Instead of bypassing the proxy, ProxyAvatar could accept absolute URLs whose host is on a small allowlist (gravatar.com, www.gravatar.com, secure.gravatar.com) and fetch those directly rather than prefixing jellyseerrUrl. That keeps avatars server-side (viewers' IPs never reach Automattic) at the cost of widening the proxy's input surface. Happy to switch to that shape if you'd prefer it.

Testing

• Reproduced on Jellyfin 10.11 / plugin 12.5.0.0 with a local Jellyseerr user's request
• Tested on Jellyfin 10.11
• Verified no basic errors

Implementation Notes

This PR was developed with AI assistance (Claude). I have reviewed and tested all changes and understand the implementation.