fix(jellyfin): typed HTTP exception instead of a status code buried in a string

[PonceGL]

What

JellyfinApiService.request() wraps every non-2xx response in
Exception("HTTP $code: ${response.message}"), so callers can't tell 401 from
429 without parsing a message string. This is one of the small independent
fixes listed in #2813.

Changes

• JellyfinHttpException(statusCode, retryAfter, message) replaces the plain
  Exception on the failure path of request(). retryAfter is passed
  through unparsed (HTTP allows either a number of seconds or an HTTP-date;
  deciding between the two is a caller concern, not this type's).
• catch (e: CancellationException) { throw e } added before the existing
  catch (e: Exception), which was silently swallowing cancellation.

Why now, and why scoped this tight

Grepped the whole codebase first: nothing parses the old message string, so
this has no other call site to update. authenticateByName() and
checkDownloadPermission() in the same file have the identical
swallowed-cancellation issue, but I left them alone here to keep this PR to
exactly the one thing it claims to do — happy to open a follow-up for those
two if useful.

Testing

5 new JUnit5 tests. No mock-server dependency added — a real
okhttp3.Response built through an Interceptor on the injected client is
enough to exercise request()'s real parsing path (status code, the
Retry-After header, and the happy path), without introducing anything new
to the test graph.

:app:testDebugUnitTest: 393 tests, same 5 pre-existing failures as
master's baseline, none new.

[PonceGL]

Self-review (code-review, medium effort)

One finding, applied: `authenticateByName()`, a few lines below `request()` in this same file, had the identical `catch (e: Exception)` that swallows `CancellationException` into a `Result.failure` — the exact bug this PR fixes, just not the method R19 named. Fixed with the same one-line pattern, plus a test mirroring the existing deterministic cancel-before-call case.

Left `authenticateByName()`'s HTTP-failure paths as plain `Exception` (not `JellyfinHttpException`) — unlike `request()`, nothing downstream needs to distinguish auth failure status codes, and that's not what R19/F3.3 ask for here.

Re-verified: 6 JVM tests (was 5), all green. Baseline unaffected — 393 tests, same 5 pre-existing failures, none new.

[PonceGL]

Closing for now — reorganizing how this work is staged. It'll go through our fork first and we'll propose it upstream again, possibly bundled differently, once the larger feature it's part of is further along. Not a rejection, just a process change on our side.