Show episode names (EPG subtitle) once the server exposes them (blocked on m3ue/m3u-editor#1409)

[Grimothy]

Blocked on

m3ue/m3u-editor#1409 — the server currently never sends the EPG programme "episode name" (XMLTV <sub-title>, e.g. "Groundhog Day" vs. the show title "The Bear") to any client-facing endpoint, even though it's parsed and stored server-side. That issue tracks exposing it in search_epg_shows, get_short_epg, and get_epg_batch.

Problem this causes today

Without an episode-specific name, the client can only distinguish airings of the same show by channel and start time. Concretely:

• DVR Shows search (flutter_client/lib/features/shows/show_detail_screen.dart, _EpisodeRow) — every episode row under a show shows the identical episode.title (the show name), differing only by channel/time label. A user can't tell "S3E1" from "S3E5" when picking which airing to record.
• Live TV EPG grid/timeline — same limitation; EpgProgram (flutter_client/lib/services/domain_models.dart:768) only has title/description, no episode-name field, so the grid can't show it either even where there'd be room.

Desired behavior (once #1409 lands server-side)

1. Add a nullable subtitle (or episodeTitle) field to:
   • EpgProgram (domain_models.dart:768) — parse from the new server field.
   • EpgShowEpisode (domain_models.dart:1181) — same.
2. Surface it in the UI:
   • _EpisodeRow in show_detail_screen.dart — show the episode name as the primary line when present (falling back to the show title when the server has none, e.g. providers that don't tag <sub-title> and the description-fallback extraction also came up empty).
   • Live TV EPG grid/now-next display — same fallback treatment.
3. Not a blocker for anything already shipped or in flight — DVR single-airing scheduling (Allow scheduling a single (or multiple) airing from DVR Shows search, not just "Record Series" #204) works correctly with or without this; it's a display-quality improvement layered on top.

Scope note

Server-side response shape isn't final until #1409's fix lands — don't start client parsing work until that PR merges and the field name/encoding (plain vs. base64, key name) is confirmed.