feat: Multiboot-Stick-Modus (mehrere macOS-Versionen auf einem USB-Stick)

- GUI: dritter Modus-Umschalter, Checkbox-Mehrfachauswahl statt Single-Select
- Backend: sgdisk partitioniert den Stick in N Apple_HFS-Partitionen (Typ AF00),
  jede mit Label = macOS-Titel/Version, jede bekommt ihr eigenes Installer-Image
  per dd -- Macs EFI-Bootpicker (Alt/Option) zeigt alle Partitionen zur Auswahl
- Groessen-Check VOR dem Schreiben: bricht mit klarer Fehlermeldung ab wenn der
  Stick zu klein ist, statt mittendrin zu scheitern
- Dockerfile: parted (partprobe) ergaenzt
- End-to-end gegen ein echtes Loop-Device verifiziert: sgdisk legt korrekte
  Partitionen mit Labels an, dd schreibt in die richtige Partition, Inhalt
  stimmt exakt ueberein (nicht nur behauptet)
- README: neuer Abschnitt 4 (Funktionsweise, Ablauf, ehrliche Grenzen),
  Multiboot als experimentell markiert (erbt recovery-Pfad-Unsicherheit bei
  Big Sur+, kein echter Mac-Boot-Test bisher durchgefuehrt)

README.md

@@ -53,9 +53,11 @@ geaendert hat — dann muss `backend/installer.py` (`_extract_recovery_dmg`)
 angepasst werden.
 
 ### 3. Offline-Bibliothek / "nur herunterladen"-Modus
-Oben in der GUI laesst sich per Umschalter zwischen zwei Modi waehlen:
+Oben in der GUI laesst sich per Umschalter zwischen drei Modi waehlen:
 
-- **"Auf USB-Stick schreiben"** (Standard) — wie bisher.
+- **"Auf USB-Stick schreiben"** (Standard) — wie bisher, eine Version, ein
+  kompletter Stick.
+- **"Multiboot-Stick (mehrere Versionen)"** — siehe Abschnitt 4 unten.
 - **"Nur herunterladen (Offline-Bibliothek)"** — laedt ausschliesslich das
   Original-Image (`BaseSystem.dmg`/`InstallESD.dmg` bzw. `InstallAssistant.pkg`,
   je nach Version) und legt es **dauerhaft** unter `./downloads/library/<name>/`
@@ -80,7 +82,53 @@ Die GUI zeigt oben die Gesamtgroesse + Anzahl bereits heruntergeladener
 Installer an, und markiert bereits vorhandene Versionen in der Auswahlliste
 mit "bereits offline vorhanden".
 
-### 4. USB-Geraete-Erkennung
+### 4. Multiboot-Stick (mehrere macOS-Versionen auf einem Stick)
+Im Modus **"Multiboot-Stick"** waehlst du in Schritt 1 statt einer Version
+per Checkbox **2 bis 8** Versionen gleichzeitig aus. Das Tool baut daraus
+einen einzigen Stick mit **einer eigenen GPT-Partition pro Version**.
+
+**Warum das funktioniert:** Macs EFI-Bootmanager (beim Start `Alt`/`Option`
+gedrueckt halten) scannt beim Boot-Picker **alle** Partitionen eines
+angeschlossenen Datentraegers nach bootfaehigen Volumes, nicht nur die
+erste. Legt man also mehrere `Apple_HFS`-Partitionen an und schreibt in
+jede das vollstaendige, fuer sich bootfaehige Installer-Image, zeigt der
+Boot-Picker automatisch alle als eigene Wahlmoeglichkeiten an. Das ist eine
+in der Mac-Community seit Jahren dokumentierte Technik, kein Neuland dieses
+Tools.
+
+**Ablauf im Backend (`backend/installer.py`, `_run_multiboot_job`):**
+1. Alle gewaehlten Images werden (aus der Bibliothek oder frisch) geladen
+   und wie im Einzel-Stick-Modus konvertiert -- ERST wenn alle fertig
+   konvertiert sind, geht's weiter (kein Halb-Zustand auf dem Stick).
+2. Anhand der tatsaechlichen Image-Groessen + Puffer (`PARTITION_PADDING_MB`)
+   wird geprueft, ob der ausgewaehlte Stick ueberhaupt gross genug ist --
+   **bevor** irgendetwas geschrieben wird. Ist er zu klein, bricht der Job
+   mit einer klaren Fehlermeldung (benoetigt vs. vorhanden in GB) ab, ohne
+   den Stick anzuruehren.
+3. `wipefs -a` + `sgdisk --zap-all` loeschen den Stick komplett, dann legt
+   `sgdisk` in einem Rutsch N Partitionen an (Typ `AF00` = Apple HFS/HFS+,
+   mit Label = Titel/Version der jeweiligen macOS-Version, sichtbar im
+   Boot-Picker).
+4. Jedes Image wird per `dd` in seine eigene Partition geschrieben
+   (`/dev/sdb1`, `/dev/sdb2`, ...), nicht auf das gesamte Geraet.
+
+**Ehrliche Einschraenkung -- als experimentell markiert:**
+- Fuer den `legacy_dmg`-Pfad (bis Catalina) ist die Technik gut etabliert
+  und robust.
+- Fuer den `recovery`-Pfad (Big Sur+) erbt Multiboot dieselbe Unsicherheit
+  wie der normale Einzel-Stick-Modus (siehe Abschnitt 2) -- kommt on top zur
+  Multiboot-Partitionierung selbst dazu. Mischungen aus alten + neuen
+  Versionen auf einem Stick sind technisch kein Problem, aber jede
+  Big-Sur+-Version im Mix bleibt der fragilste Teil.
+- Groessenbedarf: 3 Versionen macOS koennen leicht 30-50GB+ zusammen
+  ergeben, ein Stick mit 64GB+ ist fuer sinnvolle Kombinationen realistisch.
+- Es gab noch **keinen echten Boot-Test auf echter Mac-Hardware** durch
+  dieses Projekt selbst -- die Partitionierungs-/Schreib-Logik ist gegen
+  einen echten Docker-Host verifiziert (Build + Job-Ablauf), das
+  tatsaechliche "zeigt der Boot-Picker alle Partitionen an und bootet jede"
+  muss beim ersten echten Einsatz am Mac verifiziert werden.
+
+### 5. USB-Geraete-Erkennung
 Der Container laeuft mit `privileged: true` und mountet `/dev` sowie
 `/run/udev` vom Host durch &mdash; noetig, um Sticks direkt zu partitionieren
 und zu beschreiben. Das ist bewusst so gebaut, bedeutet aber: der Container
@@ -178,3 +226,9 @@ jetzt tatsaechlich Big Sur bis Tahoe zurueck).
    kein Rewrite).
 3. Kein Windows/macOS-Docker-Host-Support fuer das Device-Passthrough &mdash;
    nur natives Linux.
+4. Der Multiboot-Modus (Abschnitt 4) wurde bislang nur end-to-end bis zur
+   fertig geschriebenen Partitionstabelle/den Images verifiziert, NICHT
+   durch einen echten Boot-Test auf Mac-Hardware. Die zugrundeliegende
+   Multi-Partition-Bootpicker-Technik ist etabliertes Community-Wissen,
+   aber "funktioniert bei diesem Tool nachweislich" != "wurde von uns am
+   Mac gebootet".