docs: early_command doesn't work on Ubiquity; fix boot menu default direction

d-i preseed/early_command produced no trace anywhere (no log, no
syslog/installer-debug mention) -- Ubiquity runs its install steps via
its own Python plugin system (plugininstall.py), not the classic
debian-installer shell components that early_command/late_command are
bound to. Decided not to build a custom Ubiquity plugin or a
pre-ubiquity live-filesystem hook for this; organizational,
install-time-fixed parameters (partitioning, filesystem, branding) go
back to being baked into the personalized preseed at ISO-generation
time in the portal instead.

Also fixes a real safety bug in the test boot menus: the destructive
auto-install entry was the default (would run automatically on
timeout). Corrected to the opposite -- default is "boot from local
disk" (safe, nothing happens), the destructive install requires
actively selecting it from the menu. Verified in both the UEFI
grub.cfg and the BIOS isolinux config.

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

adr/0009-anaconda-live-kickstart-verworfen.md

@@ -200,3 +200,13 @@ Die Kernfrage dieses gesamten ADR ist damit vollständig und real beantwortet
 - Eine schlanke Debian-Netinstall-Variante für ein eigenständiges Backend („können wir irgendwann nachreichen", Nutzer-Entscheidung 31.07.2026).
 
 Nicht proaktiv fortsetzen, ohne dass der Nutzer das wieder aufgreift.
+
+## Update (01.08.2026): `d-i preseed/early_command` bei Ubiquity real widerlegt, Architektur entsprechend vereinfacht
+
+Aufbauend auf der Idee vom Vortag (Live-Kontakt zu `anode` während der Installation, um install-zeitlich fixe Vorgaben wie Partitionierung dynamisch statt vorab-eingebacken zu laden) wurde `d-i preseed/early_command` real getestet — läuft laut Debian-Installer-Dokumentation früh genug, um per `debconf-set-selections` noch vor der Partitionierung Werte zu setzen, und (anders als `success_command`) nicht gechrootet.
+
+**Ergebnis: kein Effekt, keinerlei Spur.** Weder die vom Skript selbst erzeugte Logdatei noch irgendein Hinweis in `/var/log/syslog` oder `/var/log/installer/debug` — der Befehl wurde nie ausgeführt. Journal-Fund zur Erklärung: `ubiquity: ['log-output', '-t', 'ubiquity', '--pass-stdout', '/usr/share/ubiquity/plugininstall.py'] exited with code 0` — Ubiquity führt seine Installationsschritte über ein eigenes Python-„Plugin"-System aus, nicht über die klassischen Shell-„Components" des Debian-Installers, an die `early_command`/`late_command` als Preseed-Sonderhaken gebunden sind. Kein Konfigurationsfehler, sondern eine andere Architektur — die anderen `d-i`-Direktiven (Partitionierung, Netzwerk, Nutzer) funktionierten ja bereits durchgehend, nur dieser Meta-Mechanismus nicht.
+
+**Entscheidung (01.08.2026):** Kein eigenes Ubiquity-Plugin bauen, kein Vor-Ubiquity-Hook im Live-Dateisystem — der Aufwand steht für den Pilotbetrieb nicht im Verhältnis zum Nutzen. Stattdessen zurück zu einem einfacheren, schon einmal (23.07.2026) skizzierten Modell: Organisationsspezifische, install-zeitlich fixe Vorgaben (Partitionierung, Dateisystem, Corporate-Branding) kommen bereits beim ISO-Erzeugen im Self-Service-Portal in die personalisierte Preseed-Datei — kein Live-Nachladen zur Installationszeit nötig. Die Installation kann Kundenwünsche also auch ohne `early_command` vollständig erfüllen.
+
+**Bootmenü als eigentlicher Sicherheits-Gate, mit einer wichtigen Korrektur:** Der bisher gebaute Test-Bootmenüs hatten „Tuxflotte Auto-Install" als Standardeintrag — bei Nichtstun wäre die destruktive Installation automatisch losgelaufen. Nutzer-Korrektur: richtig ist genau umgekehrt — Standard (Countdown-Ablauf) muss „von lokaler Festplatte booten" sein, die destruktive Installation nur bei aktiver, bewusster Auswahl aus dem Menü. Beide Testmenüs (`boot-grub.cfg` für UEFI, `isolinux-live.cfg` für BIOS) wurden entsprechend korrigiert und real verifiziert. Das ist jetzt der tatsächliche physische Bestätigungs-Mechanismus für ADR-0008s Auto-Modus-Gate — kein Zeitfenster zum Abbrechen, sondern eine bewusste Positiv-Auswahl, um überhaupt zu starten.

architecture/13-live-provisioning-boot.md

@@ -35,7 +35,8 @@ Server baut personalisierte, distributionsspezifische Installer-ISO
 Kunde bootet diese ISO direkt (kein Bootstrap-/Live-Zwischenschritt nötig)
  ↓
 GRUB-Countdown (konfigurierbar) — De-facto-Bestätigungsfenster:
- ↓ Standardeintrag startet automatisch, jede Taste vor Ablauf hält an
+ ↓ Standard ist "von lokaler Festplatte booten" (sicher, nichts passiert),
+ ↓ die destruktive Installation muss aktiv ausgewählt werden
  ↓
 Nativer Installer (Anaconda/Subiquity/...) startet direkt aus GRUB,
  ↓ in seiner offiziell unterstützten, unbeaufsichtigten Betriebsart —
@@ -56,7 +57,7 @@ Provisioning Agent läuft erstmalig (voller Treibersatz des installierten
 
 - Kein Übergang *innerhalb derselben Boot-Sitzung* von „interaktiv/entscheidungsfähig" zu „Installer" mehr nötig — genau dieser Übergang erforderte `kexec` und scheiterte an fehlenden Dracut-Modulen. Die Installation ist jetzt von Anfang an unbeaufsichtigt und entscheidungsfrei, weil alle Entscheidungen schon vor dem Boot im Portal getroffen wurden.
 - WLAN-Einrichtung passiert nicht mehr im eingeschränkten Installer-Initrd (schmaler Treibersatz, siehe ADR-0009), sondern erst beim ersten Boot des fertig installierten Zielsystems, mit dessen vollem, distributionsüblichem Treiberumfang.
-- Die Auto-Modus-Gate-Bestätigung (siehe unten, ADR-0008) verschiebt sich von „vor der Installation" auf „nach der Installation, vor Anwendung einer organisationsspezifischen Konfiguration": Die destruktive Installation selbst setzt nur physische Anwesenheit voraus (wer den Stick bootet, hat das bereits entschieden), die eigentlich sicherheitsrelevante Freigabe — welcher Organisation gehört dieses Gerät — bleibt bestehen, nur zeitlich auf den Agenten-Erstlauf verschoben.
+- Die Auto-Modus-Gate-Bestätigung (siehe unten, ADR-0008) läuft praktisch über zwei Ebenen, nicht mehr rein zeitlich verschoben: Das Bootmenü selbst ist der physische Sicherheits-Gate — Standardeintrag (bei Nichtstun, nach Ablauf des Countdowns) ist „von lokaler Festplatte booten", die destruktive Installation muss aktiv aus dem Menü ausgewählt werden (Erkenntnis vom 01.08.2026, korrigiert eine frühere, umgekehrte Annahme). Organisationsspezifische, install-zeitlich fixe Vorgaben (Partitionierung, Dateisystem, Corporate-Branding im GRUB) kommen bereits beim ISO-Erzeugen im Portal in die personalisierte Preseed-/Kickstart-Datei — ein Versuch, das stattdessen dynamisch zur Installationszeit von `anode` zu laden (`d-i preseed/early_command`), scheiterte real: Ubiquity führt seine Schritte über ein eigenes Python-Plugin-System aus, nicht über die klassischen Debian-Installer-Components, an die dieser Preseed-Sonderhaken gebunden ist — kein Bug, sondern eine andere Architektur. Was weiterhin auf den Agenten-Erstlauf verschoben bleibt: WLAN-Einrichtung und die Anwendung des eigentlichen Workspace/Blueprints.
 
 **Netinstall vs. DVD/Everything — Kundenwahl, kein Tuxflotte-Standard:** Beide Medienvarianten haben einen echten, sich ausschließenden Nachteil. Netinstall braucht bei der Installation selbst Netzwerk (Pakete vom Mirror) — riskant bei WLAN-only-Zielhardware, falls das Installer-Image dafür keinen passenden Treiber mitbringt (real beobachtet, siehe ADR-0009). DVD/Everything braucht dafür keine Netz zur Installationszeit, kann aber veraltet sein (Nachholbedarf beim ersten Update nach der Installation). Welche Variante sinnvoll ist, hängt vom Einsatzkontext des Kunden ab (kabelgebundene Rechner beim Erstboot vs. mobile, nur-WLAN-Geräte) — das wird deshalb als Kundenoption im Self-Service-Profil geführt, nicht als projektweite Festlegung. Tuxflotte muss beide Basis-Varianten pro Backend bauen/pflegen können, aber nicht zwangsläufig für jeden Backend sofort beide.