feat(emby): add Emby as a MediaBrowser backend alongside Jellyfin

Emby is Jellyfin's upstream ancestor and speaks a near-identical MediaBrowser
API, so the existing Jellyfin stack is parameterised by a `MediaBrowserDialect`
rather than forked. `JellyfinClient`, its auth service, endpoint discovery, LAN
discovery, and the add/edit connection screens all take the dialect and keep one
implementation; `MediaBackend.emby` and `ConnectionKind.emby` carry it through
the neutral models, the Drift `kind` discriminator, downloads, and caches.

Every divergence below was measured against a live Emby 4.9.5 server, not
inferred from documentation, and each is documented at its capability getter.
Jellyfin's request strings stay byte-identical so nothing about its behaviour
changes.

Routes and auth
- Emby only accepts the pre-10.9 user-scoped item routes (`/Users/{id}/Items/…`,
  `/Users/{id}/PlayedItems/…`, `/Users/{id}/FavoriteItems/…`); the unprefixed
  forms Jellyfin 10.11 added return 404.
- The API is also served under a legacy `/emby` prefix, and both dialects accept
  the token as `X-Emby-Token` or `api_key=`.
- Emby answers only its own LAN discovery datagram ("who is EmbyServer?") and
  ignores Jellyfin's; its default HTTPS port is 8920.
- No `/QuickConnect` route exists, so Quick Connect stays Jellyfin-only.

Row fields Emby withholds
- `ProductionYear`, `OfficialRating`, `PremiereDate` and `DateCreated` are absent
  from list rows unless named in `Fields`, which would otherwise strip the year
  and age-rating badge from every card in the app.
- `UserData.LastPlayedDate` never appears on a list row under `Fields=UserData`,
  `EnableUserData=true` or the user-scoped `Ids=` form — only on the single-item
  detail route, or when the Emby-specific `UserDataLastPlayedDate` token is
  requested. Without it every recency-ordered surface silently degrades to
  library-add time, and `JellyfinApiCache.applyWatchState` stamps
  `DateTime.now()` on watched rows, so an offline watch-state pull would rewrite
  the cached play time of everything it walked.

Continue Watching and Next Up
- Emby computes Next Up per series only: the library-wide `/Shows/NextUp` query
  returns nothing under every parameter combination tried. The shelf is
  therefore reconstructed from a played-episode recency scan plus one
  `/Shows/NextUp?SeriesId=` per distinct series, bounded by a shared wall clock
  that covers the scan as well — per-request timeouts cannot bound the pass
  because `MediaServerHttpClient` times the connect and receive phases
  independently. Rows are stamped with their series' newest play from the same
  response that ordered them, so no per-series enrichment request is needed.
- `/Shows/NextUp` ignores `NextUpDateCutoff`, and no server-side played-date
  filter exists to delegate to (`MinDatePlayed` and `MinDateLastPlayed` are
  ignored; `MinDateLastSaved`, `MinDateCreated` and `MinPremiereDate` filter
  unrelated dates), so the 365-day window is applied to the scanned dates.
- The resume route returns items with no saved position, including plain next
  episodes, so the Emby resume leg reads from `/Items?Filters=IsResumable`.
- Emby is ahead of Jellyfin in one place: `/Users/{id}/Items/{id}/HideFromResume`
  makes Continue Watching removal a real capability.

Everything else
- `/Sessions/Playing` and `/Sessions/Playing/Progress` reject a body with no
  `PlaySessionId` (HTTP 400), so playback reporting always sends one.
- Passing any `MediaTypes` value to the playlist query returns an empty list.
- There is no aggregate `/Items/Filters` route; the four filter facets are
  reassembled from `/Genres`, `/OfficialRatings`, `/Studios` and `/Tags`.
- Metadata writes take name-pair lists (`Genres: [{'Name': 'Action'}]`); the
  plain string array is accepted and then silently discarded.
- Custom artwork uploads must be base64 text, not raw bytes — which was broken
  for Jellyfin too and is fixed for both.
- Trickplay, media segments and lyrics 404 on Emby, so scrub previews are absent
  and intro/credit markers fall back to chapter names.

Verified against a local Emby 4.9.5 and a Jellyfin 10.11.11 control server:
onboarding, browse, detail, playable stream URLs serving real bytes, subtitle
sidecars, watch-state write and restore, hubs, cross-server aggregation and
search across both backends simultaneously.

lib/services/playback_progress_tracker.dart

@@ -3,7 +3,6 @@ import '../media/ids.dart';
 
 import '../mpv/mpv.dart';
 
-import '../media/media_backend.dart';
 import '../media/media_item.dart';
 import '../media/media_server_client.dart';
 import '../media/media_source_info.dart';
@@ -17,17 +16,17 @@ import '../utils/watch_state_notifier.dart';
 
 /// Tracks playback progress and reports it to the active media server.
 ///
-/// Both Plex and Jellyfin go through the unified
+/// Plex and both MediaBrowser dialects go through the unified
 /// [MediaServerClient.reportPlayback*] surface — Plex maps the three signals
-/// onto `/:/timeline` updates with appropriate `state`, Jellyfin uses the
-/// three `/Sessions/Playing*` endpoints.
+/// onto `/:/timeline` updates with appropriate `state`, while MediaBrowser
+/// uses the three `/Sessions/Playing*` endpoints.
 ///
 /// Local watched state flips as soon as the position crosses the client's
 /// [MediaServerClient.watchedThreshold] (per-server pref on Plex, fixed 90% on
-/// Jellyfin). The *server-side* mark is a separate decision: both backends
-/// already mark an item played from a threshold crossing they observe in the
+/// MediaBrowser). The *server-side* mark is a separate decision: each backend
+/// already marks an item played from a threshold crossing it observes in the
 /// reports this tracker sends, so an explicit mark is issued only for sessions
-/// that gave them no such crossing (#1287, #1740).
+/// that gave it no such crossing (#1287, #1740).
 class PlaybackProgressTracker {
   /// Server client for online progress updates (null when offline). Pinned
   /// for the tracker's lifetime — one playback session against the server
@@ -429,7 +428,7 @@ class PlaybackProgressTracker {
   /// Records what the backend actually received, then re-evaluates whether the
   /// explicit mark is still needed.
   ///
-  /// Both backends mark an item played from a watched-threshold *crossing*
+  /// Every supported backend marks an item played from a watched-threshold *crossing*
   /// observed inside a single reporting session — a report below the threshold
   /// followed by one at or above it. Absolute position is not enough: a session
   /// whose every report sits above the threshold, or one resuming past it, is
@@ -579,7 +578,7 @@ class PlaybackProgressTracker {
 
   int? _currentAudioStreamIndex(MediaSourceInfo info) {
     final playerAudioTracks = player.state.tracks.audio.where((t) => t.id != 'auto' && t.id != 'no').toList();
-    if (metadata.backend == MediaBackend.jellyfin &&
+    if (metadata.backend.usesMediaBrowserApi &&
         (info.audioTracks.any((track) => track.isExternal) || playerAudioTracks.length <= 1)) {
       final selectedSourceTrack = _selectedSourceAudioTrack(info);
       if (selectedSourceTrack != null) return selectedSourceTrack.id;