Remove the dead MediathekView catalog subsystem (drops the SharpCompress NU1902 vulnerability)

[ChrisonSimtian]

Description

src/Infrastructure/Catalog/MediathekView/ is dead DR-001-era code: the MediathekView filmliste
parser from when Krautwatch was a standalone Mediathek browser. DR-010 replaced that direction — the
catalog is now built by the per-broadcaster crawler agents (ARD/KiKA, ZDF) hitting the broadcasters'
own APIs — and MediathekView is explicitly de-emphasised there.

Removing it is not just tidiness; it carries a security cost today:

• FilmlisteParser.cs is the only consumer of SharpCompress (it needs XZ/LZMA2 to decompress
  the filmliste), and SharpCompress 0.38.0 has a known moderate severity advisory —
  NU1902 / GHSA-6c8g-7p36-r338. That warning currently fires on every build of
  src/Infrastructure, which means it ships in every host.

Related loose ends from the same era:

• AppSettings.CatalogProviderKey still defaults to "mediathekview".
• InfrastructureServiceExtensions.AddMediathekViewCatalogProvider(...) still exists.
• The ICatalogProvider port in Domain/Interfaces should be re-examined — DR-010 notes the
  provider/port abstraction survives, but it is worth confirming whether ICatalogProvider is still
  earning its place now that IBroadcasterCrawler is the real extension point, or whether it is
  vestigial too.

Usage Example

After removal, a build of src/Infrastructure should be free of NU1902, and:

grep -ri mediathekview src/   # → no hits outside docs/architecture (DR-001 history)

AppSettings.CatalogProviderKey either goes away or stops defaulting to a provider that no longer
exists.

Alternative

Bump SharpCompress to a patched version and keep the dead subsystem. That silences the advisory but
keeps unused code, an unused dependency, and a misleading default setting in the model — trading a
one-line pin for permanent confusion about how the catalog is actually built.

Notes

Care needed on two points, so this is not a blind rm -rf:

1. Check whether ICatalogProvider / AddMediathekViewCatalogProvider is still referenced by any
   host or test before deleting.
2. AppSettings.CatalogProviderKey is a persisted column — changing or dropping it needs an EF
   migration, and existing rows hold "mediathekview".

[ChrisonSimtian]

On hold as of 2026-07-28 — please do not action this yet.

I filed this partly for the SharpCompress NU1902 advisory. That motivation is gone: the advisory
was resolved by bumping SharpCompress 0.38.0 → 0.50.1 in #53, so there is no security pressure to delete
anything.

The remaining motivation was "dead DR-001-era code", and researching #6 undermined that framing. Per
DR-011, MediathekArr — the closest
comparable — is built entirely on MediathekViewWeb, i.e. the filmliste. It is the only full-catalog
source available for German public TV: ARD/ZDF publish no "give me everything" endpoint, which is exactly
why per-show crawling needs a work-list at all.

So Infrastructure/Catalog/MediathekView is not obviously dead — it is the fallback if per-show crawling
via the direct APIs proves too narrow (see #58 for the search-model work that will settle this).

Keeping open but blocked on the search-model decision. The two genuinely-stale bits can still be cleaned up
independently if wanted:

• AppSettings.CatalogProviderKey defaulting to "mediathekview" when nothing reads it.
• Whether ICatalogProvider is still earning its place now that IBroadcasterCrawler is the real extension
  point.