docs(savepoint): install.sh und README-Umbau nachgetragen

Der Block dokumentiert jetzt auch die letzte Runde: ein Befehl statt
Checkliste, README neu aufgebaut, VM-CPU-Anleitung drin.

Ehrlich als UNGETESTET markiert (neuer Punkt 6): install.sh ist nie als root
durchgelaufen. Auf dieser VM sind alle root-Schritte No-Ops - Verzeichnisse
liegen da, die Propagation ist schon shared - und sudo verlangt hier ein
Passwort. Bewiesen sind Laufwerkserkennung (SCSI-Abgleich gegen die echte
Hardware), die .env-Logik in drei Faellen und die Syntax. Das Anlegen der
Verzeichnisse, mount --make-rshared und die systemd-Unit laufen erst bei einer
echten Neuinstallation - das gehoert in die Uebergabe statt in eine
Erfolgsmeldung.

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

SAVEPOINT.md

@@ -95,6 +95,59 @@ geworden. Zwei Lücken bleiben, beide **nicht gebaut, als Vorschlag**:
 - **Mehrere Laufwerke gleichzeitig.** Rippy sieht sie (`/dev/sr[0-9]*`), ob
   parallel gerippt wird, ist **unbewiesen** — mit einem Laufwerk nicht testbar.
 
+### Installation: ein Befehl statt Checkliste (`install.sh`)
+
+Commander-Rückmeldung: „Das Docker Deployment ist mir zu kompliziert." Zu
+Recht — es war eine Sechs-Schritte-Checkliste, von der zwei Punkte Fachwissen
+verlangten. Jetzt:
+
+```bash
+git clone <repo-url> rippy && cd rippy
+sudo ./install.sh
+```
+
+Der schlimmste Punkt war das **Laufwerk**: MakeMKV braucht ZWEI Geräteknoten,
+und die sg-Nummer ist je Host anders. Das Skript gleicht sie über die
+SCSI-Adresse in `/sys` ab statt zu raten — auf der VM gegengeprüft
+(`sr0 → 3:0:0:0`, `sg1 → 3:0:0:0` = dasselbe Gerät, korrekt erkannt). Dazu:
+Verzeichnisse, Mount-Propagation **inklusive neustart-fester systemd-Unit**
+(vorher stand in der README nur „reboot-fest persistieren", ohne zu sagen wie —
+nach einem Reboot scheiterte das NAS-Einhängen aus dem UI stillschweigend),
+`.env` schreiben ohne Bestehendes zu überschreiben, bauen, starten.
+`./install.sh --nur-pruefen` sieht nur nach. Wiederholbar, damit auch der
+Update-Weg: `git pull && sudo ./install.sh`.
+
+**Zwei Fallgruben fielen beim Testen auf, beide meine eigenen:**
+- `--nur-pruefen` verlangte root und brach ab — ein Prüf-Modus, der nichts
+  ändert, darf daran nicht scheitern.
+- `.env.example` hatte `OPTICAL_SG=/dev/sg1` **unkommentiert** vorbelegt. Der
+  Installer hätte den erkannten Wert deshalb nicht eingetragen („steht schon
+  drin") und auf jedem fremden Host still eine kaputte Konfiguration
+  hinterlassen — genau das, was er verhindern soll. Beide Gerätezeilen sind
+  jetzt auskommentiert (Compose hat ohnehin Vorgaben), plus eine Gegenprobe:
+  zeigt ein wirksamer Wert auf ein Gerät, das es hier nicht gibt („`.env` von
+  einem anderen Rechner"), wird das benannt statt kryptisch von Docker gemeldet.
+
+Die `.env`-Logik ist in drei Fällen auf der VM geprüft: frische Datei bekommt
+den erkannten Wert, ein selbst gesetzter Wert bleibt unangetastet, zweimal
+ausführen erzeugt genau eine Zeile.
+
+### README neu aufgebaut
+
+Vorher 293 Zeilen, in denen der Schnellstart zwischen `lsscsi`, sg-Knoten,
+USB-Passthrough und `mount --make-rshared` begraben war. Jetzt: Installation in
+zwei Zeilen oben, dann die Tabelle „Wenn etwas nicht geht" mit den vier Fällen,
+die praktisch alles abdecken. Alles Technische darunter in aufklappbaren
+Abschnitten, inklusive der Handarbeits-Variante.
+
+**Neu und ausdrücklich gewünscht: „Rippy schneller machen"** — der VM-CPU-Typ.
+Warum Virtualisierer eine generische CPU ohne AVX2 geben, was das kostet
+(gemessene 28–55 h je 4K-Film), die genauen Proxmox-Schritte (herunterfahren →
+Hardware → Processors → Type auf `host` → starten, bzw. `qm set <vmid> --cpu
+host`), **warum ein Neustart von innen nicht genügt**, und wie man nachprüft:
+Rippy zeigt die Vektorbefehle selbst an. Dazu der Nachteil (keine
+Live-Migration auf andere CPUs) und die Alternative `x86-64-v3` für Cluster.
+
 ### NOCH OFFEN
 
 1. **Externe Worker im Praxistest** (Commander).
@@ -105,7 +158,14 @@ geworden. Zwei Lücken bleiben, beide **nicht gebaut, als Vorschlag**:
    settings-Tabelle. Für Heimnetz erwartbar, aber der Webhook ist eine echte
    Zugangsberechtigung.
 5. **Der VM-CPU-Typ steht auf `qemu64`.** `host` würde AVX2 freischalten und
-   jeden Software-Encode 2–4× beschleunigen. Ein VM-Neustart, nicht gemacht.
+   jeden Software-Encode 2–4× beschleunigen. Ein VM-Neustart, nicht gemacht —
+   **die Anleitung steht jetzt in der README** („Rippy schneller machen").
+6. **`install.sh` ist nie als root durchgelaufen.** Auf dieser VM sind alle
+   root-Schritte No-Ops (Verzeichnisse da, Propagation schon `shared`), und
+   `sudo` verlangt hier ein Passwort. Bewiesen sind Laufwerkserkennung,
+   `.env`-Logik (drei Fälle) und Syntax; **ungetestet bleiben das Anlegen der
+   Verzeichnisse, `mount --make-rshared` und die systemd-Unit** — die laufen
+   erst bei einer echten Neuinstallation.
 
 ---