fix(jellyfin): send modern Authorization header on internal and admin requests

[maun200]

Problem

Jellyfin 12 ignores the legacy X-Emby-Authorization / X-Emby-Token request headers. Sent against Jellyfin 12.1:

Header	POST /Users/AuthenticateByName (unknown user)
X-Emby-Authorization: MediaBrowser Client="…", …	400 Value cannot be null. (Parameter 'request.App')
Authorization: MediaBrowser Client="…", …	401 (expected)

Token-only requests fail the same way (401 even with a valid key).

Client proxying on dev already moved to Authorization in 1d11bcd. A few server-side call sites still send only the legacy headers, so on Jellyfin 12 they go out unauthenticated:

• BackendLibraryIndexing / BackendLibraryRefresh: API key via X-Emby-Token
• AdminHelperService.CreateJellyfinRequest: API key via X-Emby-Authorization
• AdminAuthController: avatar fetch via X-Emby-Token
• JellyfinAdminController.CreateJellyfinRequestForSession: sent both legacy headers

Change

All of these now send Authorization: MediaBrowser … Token="…" through the existing AuthHeaderHelper.CreateAuthHeader. Older Jellyfin releases accept this form too. The duplicate X-Emby-Token in JellyfinAdminController is dropped, because the full header already carries the token.

BackendLibraryIndexingTests now asserts the Authorization header instead of X-Emby-Token.

Testing

• dotnet test on dev with and without this change: the same 593 tests fail in both runs. All of them are environment-only (ALLSTARR_TEST_POSTGRES not set, no docker binary in the SDK container). There are no new failures.
• The affected test classes (BackendLibraryIndexing, AdminAuthController, JellyfinAdmin*, BackendLibraryRefresh, AdminHelper*): 19/19 passed.
• I found the underlying issue while running v2.0.3 against Jellyfin 12.1 (client logins failed with the 400 above). We run a build-time patch equivalent to this change in production.

🤖 Generated with Claude Code