docs: Konzept fuer Rippy v2 + drei Commander-Entscheide (28.08.2026)

WAS: KONZEPT-V2.md neu — Systemarchitektur, Daten-/Queue-Strategie, die
drei Betriebsmodi, API-/Event-Design, Migrationsplan V2-0 bis V2-7.
KONZEPT.md §10 und ROADMAP.md ziehen nach.

WARUM: Rippy soll drei Betriebsarten bekommen statt einer — Docker,
native Windows-App ohne Docker, Headless-Linux-Dienst; alle mit
demselben Webinterface. Das traegt technisch nur, wenn es EINEN Kern
gibt, dessen Betriebsmodus nur die Auswahl der Treiber hinter vier
Ports ist (Store, Queue, Bus, Drives).

Drei Entscheide des Commanders sind eingearbeitet:

- Reihenfolge: Echtzeit (SSE statt Polling) VOR der Windows-App. Die
  Windows-App braucht SQLite und die lokale Queue ohnehin.
- Disc-Schluessel: automatischer Abruf MIT Rueckfallebene, als Kette in
  drei Stufen (eigener Bestand -> Abruf -> Import von Hand). Das
  verschiebt die Grenze aus KONZEPT.md §10 vom 25.07.2026 bewusst —
  deshalb steht sie dort jetzt ausdruecklich fortgeschrieben statt
  still ersetzt (AGENTS Regel B). Bezugsadresse leer vorbelegt,
  Fehlschlag laut, Bestand wird nie still ueberschrieben.
- Speicherziele: der Host mountet, Rippy prueft und erzeugt die
  kopierbare Zeile. Raeumt die URSACHE der CIFS-Ausfaelle ab (Befund
  26.07.2026: die Verbindung lebt in der Netz-Namespace des
  api-Containers und stirbt mit ihm) statt weiter das Symptom zu
  heilen. SYS_ADMIN, DAC_READ_SEARCH, apparmor:unconfined und die
  Mount-Wache fallen damit weg.

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

KONZEPT.md

@@ -220,3 +220,52 @@ Ein modular aufgebautes System, das bei Disc-Einwurf automatisch den Typ erkennt
   Episoden-Zuordnung per Laufzeitabgleich (TMDB) — erfüllt Etappe-12-Ziel
   „Serien-Episoden-Erkennung" in der ersten Ausbaustufe (nur bei
   EINDEUTIGER Zuordnung wird umbenannt).
+- **28.08.2026 — DISC-SCHLÜSSEL: die Grenze vom 25.07. ist verschoben
+  (Commander-Entscheid).** Der Eintrag vom 25.07.2026 oben sagt: *„Rippy
+  liefert und verteilt KEINE Disc-Schlüssel und lädt auch keine herunter."*
+  **Das gilt ab jetzt nicht mehr unverändert.** Auf ausdrückliche Entscheidung
+  des Commanders bekommt Rippy v2 einen automatischen Abruf — mit den
+  bisherigen Wegen als Rückfallebene. Umgesetzt als Kette in DREI Stufen, die
+  der Reihe nach abgearbeitet wird und anhält, sobald eine trägt:
+
+  1. **Eigener Bestand** (Schlüsselspeicher der Installation) — immer zuerst.
+     Gefüllt vom Windows-Knoten, der die Schlüssel über die eigene
+     MakeMKV-Lizenz selbst abruft (unter Linux tut `makemkvcon` das nie,
+     Messung 25.07.2026), und von jedem Import.
+  2. **Automatischer Abruf** von der konfigurierten Quelle — wenn Stufe 1
+     die Disc nicht kennt.
+  3. **Import von Hand** (`_private_data.tar`, `KEYDB.cfg` über das UI) —
+     unverändert aus v1.
+
+  Fünf Regeln gehören zum Entscheid dazu: (a) die Bezugsadresse steht in der
+  KONFIGURATION und ist LEER vorbelegt — ohne Eintrag ist Stufe 2
+  übersprungen; eine vorbelegte Adresse, die irgendwann tot ist, wäre genau
+  die Falle aus `.env.example` („lässt die Konfiguration gesund aussehen und
+  den Bau später scheitern"). (b) Ein funktionierender Bestand wird NIE still
+  überschrieben — neue Datei daneben, prüfen, dann tauschen. (c) Ein
+  Fehlschlag ist LAUT (kein `except: pass`, Meldung im Log und im UI).
+  (d) Das UI zeigt Herkunft und Alter jedes Eintrags. (e) **Rippy bringt
+  selbst nichts mit** — weder Installer noch Docker-Image enthalten Schlüssel
+  oder eine vorbelegte Bezugsadresse; was abgerufen wird, trägt der Betreiber
+  der Installation ein. Ausführlich in `KONZEPT-V2.md` § 7.5 und § 10.
+- **28.08.2026 — SPEICHERZIELE: der Host mountet, Rippy prüft
+  (Commander-Entscheid).** Das Muss-Feature „NFS/Bind-Mount für Medien-Store"
+  (§ 6) bleibt; was wegfällt, ist das Mounten DURCH Rippy. Begründung ist der
+  Befund vom 26.07.2026: Die CIFS-Verbindung lebt in der Netz-Namespace des
+  api-Containers und stirbt mit ihm — dagegen läuft heute eine Mount-Wache.
+  In v2 hängt der Host ein (fstab, `.mount`-Unit oder Compose-Volume-Treiber),
+  und Rippy erzeugt dafür die fertige, kopierbare Zeile. Die Eingabemaske im
+  UI bleibt; der Knopf „Verbinden" wird zu „Zeile kopieren". Die gesamte
+  PRÜF-Logik aus `mounts.py` bleibt erhalten (Erreichbarkeit mit Zeitgrenze
+  im Kindprozess, SMB-Klartextfehler, Pfad-Map-Vorschlag). Folge:
+  `CAP_SYS_ADMIN`, `DAC_READ_SEARCH`, `apparmor:unconfined`,
+  `propagation: rshared` und die Mount-Wache fallen ersatzlos weg.
+- **28.08.2026 — RIPPY v2: drei Betriebsmodi statt eines
+  (Commander-Auftrag).** Die Multi-Container-Architektur aus § 6 bleibt als
+  EINER von drei Modi bestehen. Dazu kommen eine native Windows-Installation
+  ohne Docker und eine Headless-Linux-Anwendung — beide mit demselben
+  Webinterface. Technisch tragen alle drei denselben Kern; ein Modus ist nur
+  die Auswahl der Treiber hinter vier Ports (Store, Queue, Bus, Drives).
+  Damit sind Postgres und Redis für Einzelinstallationen keine Pflicht mehr
+  (SQLite + lokale Queue), bleiben im verteilten Modus aber unverändert.
+  Vollständige Spezifikation: **`KONZEPT-V2.md`**, Etappen in `ROADMAP.md`.