fix(build): der MakeMKV-Fallback der VM war seit Monaten tot - Kette jetzt dreistufig

Beim Aufraeumen der VM-.env aufgefallen und nachgemessen (25.07.2026):

    https://www.makemkv.com/download        HTTP 200   <- Repo-Standard
    https://www.makemkv.com/download/old    HTTP 525   (Cloudflare)
    web.archive.org-Schnappschuss           HTTP 404   <- stand in der VM-.env

Die VM zeigte also auf eine KAPUTTE Adresse. Aufgefallen ist es nie, weil dort
die vendor/-Tarballs liegen und der Download-Zweig gar nicht erreicht wird.
Nimm die Tarballs weg, und jeder Bau scheitert mit 404 - waehrend die
Konfiguration gesund aussieht. Genau diese Sorte Fehler ist bei einer Uebergabe
teuer, weil sie erst beim Fremden zuschlaegt.

## Bereinigt (auf Commander-Wunsch, Sicherung liegt auf der VM)

.env.sicherung-vor-aufraeumen-20260725 angelegt, dann:
- MAKEMKV_URL_BASE raus -> es gilt der Compose-Standard, der liefert.
  Von Docker gegengeprueft: MAKEMKV_URL_BASE: https://www.makemkv.com/download
- JWT_SECRET_KEY raus -> Ueberrest der in v3.4 ausgebauten Anmeldung, wirkungslos.

## Fallbacks BEHALTEN, aber echt gemacht (Commander-Vorgabe)

Vorher war der "Fallback" eine Zeile, die man von Hand eintragen musste - und
die hier ins Leere zeigte. Jetzt eine automatische Kette:

  1. vendor/-Tarballs        (braucht kein Netz, zuverlaessigster Weg)
  2. MAKEMKV_URL_BASE
  3. MAKEMKV_URL_FALLBACK    (NEU, wird automatisch versucht wenn 2 versagt)

Stufe 3 ist ABSICHTLICH leer vorbelegt. Es gibt derzeit keine belegbare zweite
Quelle (siehe Messung oben), und eine einzutragen, die nicht liefert, waere
schlimmer als keine - genau das lag auf der VM vor. Wer eine eigene Quelle hat
(Spiegel im LAN), traegt sie ein und sie wird automatisch genutzt.

Scheitert alles, nennt die Fehlermeldung jetzt die beiden Wege, die
FUNKTIONIEREN, statt nur einen curl-Rueckgabewert zu hinterlassen.

## Geprueft, beide Zweige

- vendor-Pfad:   Bau durch, 828 MB
- Download-Pfad: im FREMDEN Klon ohne Tarballs gebaut - Bau durch, 777 MB,
  makemkvcon liegt unter /usr/local/bin/. Die leere Fallback-Stufe wird
  korrekt uebersprungen, "Erste Quelle lieferte nicht" erschien nicht.

docker compose config validiert. README und .env.example nennen die gemessenen
HTTP-Antworten, damit niemand wieder eine 404-Adresse als Fallback eintraegt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.env.example

@@ -51,3 +51,23 @@ MAKEMKV_APP_KEY=
 #   docker compose build worker && docker compose up -d worker
 # (bei Cloudflare-Zicken vorher Tarballs nach docker/worker/vendor/ legen)
 #MAKEMKV_VERSION=1.18.4
+
+# ---------------------------------------------------------------------------
+# MakeMKV-Bezug beim Image-Bau (nur nötig, wenn der Download klemmt)
+# ---------------------------------------------------------------------------
+# Am 25.07.2026 nachgemessen, welche Quellen wirklich liefern:
+#   https://www.makemkv.com/download        HTTP 200  <- der Standard, funktioniert
+#   https://www.makemkv.com/download/old    HTTP 525  (Cloudflare)
+#   web.archive.org-Schnappschuss           HTTP 404
+# Normalerweise ist hier NICHTS einzutragen.
+#MAKEMKV_URL_BASE=https://www.makemkv.com/download
+#
+# Zweite Quelle, die bei Fehlschlag der ersten automatisch probiert wird.
+# Trage hier nur etwas ein, das du selbst geprüft hast — eine Adresse, die nicht
+# liefert, lässt die Konfiguration gesund aussehen und den Bau später scheitern.
+# Genau so lag es auf der Rippy-VM: dort stand eine 404-Adresse, und nur die
+# vendor-Tarballs retteten jeden Bau, ohne dass es jemandem auffiel.
+#MAKEMKV_URL_FALLBACK=http://192.168.178.10:8099
+#
+# Der zuverlässigste Weg bleibt ohne Netz: Tarballs von makemkv.com/download
+# laden und nach docker/worker/vendor/ legen — der Bau nimmt sie dann von dort.