chore(handoff): portabel machen + Doku/Onboarding glaetten (Review-Umsetzung)

Aus dem Weitergabe-Review. Kein Verhaltenswechsel fuer den Ursprungs-Host
(alle Defaults = bisheriges Verhalten):

Portabilitaet:
- Laufwerk-Geraeteknoten via .env parametrisiert (OPTICAL_SR/OPTICAL_SG,
  Defaults sr0/sg1) - der #1-Blocker: auf Fremdhosts liegt das sg-Node woanders.
- deploy.sh generisch (RIPPY_VM/RIPPY_REPO_URL/... aus der Umgebung) - keine
  festen Besitzer-Adressen (interne IP + DDNS) mehr im Repo.
- POSTGRES_PASSWORD in compose durchverdrahtet (Default rippy) - war No-op.

Aufraeumen (toter/irrefuehrender Code):
- udev/ entfernt (fehlende Regeldatei, falscher Container-Name; durch ioctl-
  Polling ersetzt - reine Altlast).
- docker/postgres/*, docker/redis/*, init.sql entfernt (nie eingebunden).

Onboarding:
- FirstRunWizard verdrahtet: App.tsx fragt GET /setup und zeigt den
  Einrichtungs-Assistenten beim ersten Start (war gebaut, aber nie gerendert).

Doku:
- README: Laufwerk-Abschnitt auf .env, ENV-Tabelle (OPTICAL_*/POSTGRES),
  rshared-Anleitung, neuer Abschnitt "Haertung fuer fremde/exponierte Netze".
- config_validation.py: TMDB Pflicht->empfohlen, Zeichensalat-Tippfehler gefixt.
- .env.example: TMDB-Wording, OPTICAL_*-Variablen.

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

README.md

@@ -21,20 +21,23 @@ ersten Mal automatisch (API-Keys, Verarbeitung, erkannte Hardware).
 
 ### Laufwerk anpassen
 
-Standard ist `/dev/sr0` (+ `/dev/sg1` für den Worker — MakeMKV spricht
-Laufwerke über die SCSI-Generic-Schicht an). Andere Geräte? Lege eine
-`docker-compose.override.yml` an:
+Der Worker braucht **zwei** Host-Geräteknoten: den CD-ROM-Knoten (meist
+`/dev/sr0`) und den passenden **SCSI-Generic-Knoten** (`/dev/sgN`) — MakeMKV
+spricht Laufwerke über die sg-Schicht an. Die sg-Nummer ist **je Host anders**
+(auf frischen Systemen oft `/dev/sg0`).
 
-```yaml
-services:
-  api:
-    devices: ["/dev/sr1:/dev/sr0"]
-  worker:
-    devices: ["/dev/sr1:/dev/sr0", "/dev/sg2:/dev/sg1"]
+Ermitteln, welche Knoten dein Blu-ray/DVD-Laufwerk hat:
+```bash
+lsscsi -g          # zeigt Modell + zugehörigen /dev/sgN
+# oder: ls -la /sys/class/scsi_generic/
 ```
-
-Welche sg-Nummer dein Laufwerk hat, verrät `lsscsi -g` oder
-`ls -la /sys/class/scsi_generic/`.
+Dann in der `.env` eintragen (Defaults passen für den Ursprungs-Host):
+```bash
+OPTICAL_SR=/dev/sr0    # CD-ROM-Knoten deines Laufwerks
+OPTICAL_SG=/dev/sg0    # sg-Knoten deines Laufwerks
+```
+`docker compose up -d` nutzt diese Werte. (Für Feineinstellungen geht weiterhin
+eine `docker-compose.override.yml` mit eigenen `devices:`-Einträgen.)
 
 **Laufwerk in einer VM?** Per USB-Passthrough anhand der Vendor-ID
 durchreichen (Proxmox: `qm set <vmid> -usb0 host=xxxx:yyyy,usb3=1`) —
@@ -150,6 +153,9 @@ bleibt All-in-one.
 | `THETVDB_API_KEY` | optional | Serien-Fallback |
 | `MAKEMKV_APP_KEY` | optional | MakeMKV-Beta-Key (Forum); DVDs gehen ohne — bequemer: im UI unter Einstellungen → System pflegen |
 | `MAKEMKV_URL_BASE` | optional | alternative Download-Quelle für den Image-Build |
+| `OPTICAL_SR` | je Host | Host-Pfad des CD-ROM-Knotens (Default `/dev/sr0`) — siehe „Laufwerk anpassen" |
+| `OPTICAL_SG` | je Host | Host-Pfad des sg-Knotens des Laufwerks (Default `/dev/sg1`; oft `/dev/sg0`) |
+| `POSTGRES_PASSWORD` | optional | DB-Passwort (Default `rippy`) — für exponierte Umgebungen ein starkes Passwort setzen |
 
 UI-Einstellungen (Wizard/Settings) überstimmen die Env-Variablen.
 
@@ -165,7 +171,16 @@ Voraussetzungen auf dem Ziel-Host:
    In einer VM: per **USB-Passthrough** (Vendor-ID) durchreichen, NICHT
    als emuliertes CD-ROM — siehe „Laufwerk anpassen" oben.
 3. Ablage-Basis anlegen: `mkdir -p /srv/rippy/media` (oder Pfad in
-   `docker-compose.yml` anpassen — muss ein rshared-fähiger Bind sein).
+   `docker-compose.yml` anpassen). Der Bind nutzt **shared/slave-Propagation**
+   (fürs In-UI-Einhängen von NAS-Freigaben). Auf den meisten systemd-Linux-Hosts
+   ist `/` schon `rshared`, dann ist nichts zu tun. Bricht `docker compose up`
+   mit *„path … is mounted on / but it is not a shared mount"* ab, einmalig:
+   ```bash
+   sudo mount --bind /srv/rippy/media /srv/rippy/media
+   sudo mount --make-rshared /srv/rippy/media
+   ```
+   (reboot-fest als systemd-`.mount`-Unit persistieren.) Braucht einen klassischen
+   Linux-Docker-Host mit `SYS_ADMIN` — nicht Docker-Desktop/rootless/Podman.
 
 Dann wie im Schnellstart: klonen, `.env` füllen, `docker compose up -d
 --build`, `http://<host>` öffnen — der Einrichtungs-Assistent führt durch
@@ -175,6 +190,25 @@ docker compose up -d --build`.
 Nicht mitnehmen musst du: Gitea, Arcane, den CI-Runner — das ist die
 Entwicklungs-Infrastruktur DIESER Installation, nicht Teil von Rippy.
 
+### Härtung für fremde/exponierte Netze
+
+Rippy ist bewusst **Heimnetz-only**: Es hat **keine Authentifizierung**, und
+Redis + PostgreSQL veröffentlichen Ports auf allen Interfaces (für Remote-Worker).
+Im vertrauten LAN ist das ein akzeptierter Kompromiss — **exponiere Rippy niemals
+ungeschützt an ein unsicheres oder öffentliches Netz.** Wer es weiter absichern will:
+
+- **Zugriff kapseln:** API (`:8000`) und UI hinter einen Reverse-Proxy mit Auth
+  (Basic-/Forward-Auth) legen oder nur über VPN erreichbar machen; Port `8000`
+  nicht auf `0.0.0.0` binden.
+- **DB/Broker abschotten:** `POSTGRES_PASSWORD` in der `.env` auf ein starkes
+  Passwort setzen; die Ports `5432`/`6379` nur an ein internes/VPN-Interface binden
+  (z. B. `"10.0.0.5:5432:5432"`) statt an `0.0.0.0`; Redis mit `--requirepass
+  <geheim>` starten und das Passwort in `REDIS_URL` ergänzen.
+- **CORS:** `main.py` erlaubt aktuell `*` (nötig, weil UI und API getrennte Ports
+  sind) — hinter einem Proxy auf die echte UI-Herkunft einschränken.
+- **NAS-Zugangsdaten** liegen bewusst im Klartext in der DB — ein weiterer Grund,
+  den DB-Port nie offen ins unsichere Netz zu hängen.
+
 ## Entwicklung
 
 CI („Ampel") läuft bei jedem Push: Ruff, pytest, Vite-Build. Es gibt genau