fix: Deinstaller, Verwaltungsfenster, Dashboard-Widerspruch, Mount-Tempo

Vier Meldungen des Commanders, alle nachgemessen.

1. DEINSTALLER LIEF NICHT MEHR - reproduziert mit echtem PowerShell:

     Der Typ [System.Windows.Forms.MessageBox] wurde nicht gefunden.

   `Add-Type -AssemblyName System.Windows.Forms` stand EINE ZEILE ZU SPAET, die
   MessageBox wurde davor benutzt. Der Deinstaller starb also in seiner ersten
   Arbeitszeile, jedes Mal. Zwei weitere Maengel gleich mit:
   Kodierung war ASCII trotz Umlauten, und `Remove-Item -Recurse -Force
   $PSScriptRoot` loescht den Ordner, in dem das laufende Skript liegt - das
   klappt auf Windows nicht zuverlaessig (venv-DLLs sind geladen). Jetzt raeumt
   ein losgeloestes cmd nach, sobald PowerShell weg ist. Der erzeugte Deinstaller
   ist gegengeprueft: parst, BOM da, Umlaute intakt.

2. VERWALTUNGSFENSTER (Doppelklick aufs Tray). Zeigt Status, Aufgaben und Log,
   plus Knoepfe fuer Rippy, Log-in-Rippy und Deinstallieren - Deinstallieren geht
   damit auch aus dem Tray-Menue. Eigener PROZESS statt Fenster im Tray, weil
   pystray und tkinter beide den Haupt-Thread wollen; tkinter statt WinForms,
   weil es bei jeder Windows-Python-Installation dabei ist. Headless gerendert
   und angesehen. Alles Fachliche kommt von Rippy (/capabilities, /jobs), damit
   dort nicht eine zweite, abweichende Wahrheit steht.

3. DASHBOARD-WIDERSPRUCH. Oben stand "Akira im Laufwerk erkannt", die
   Server-Status-Karte gleichzeitig "Bereit - keine Disc in Arbeit / Disc
   einlegen". Zwei Aussagen, ein Blick. Die Karte fragt jetzt /devices und sagt
   "Disc erkannt - wartet auf Rippen starten" samt Titel.

4. MOUNT-TEMPO. Der Commander: "150 Sekunden? Das ist verrueckt langsam." Recht
   hat er. Gemessen ging die Zeit fast komplett in einen FEHLVERSUCH: `umount -l`
   ist lazy, der Abbau passiert spaeter, und wer direkt danach mountet, riskiert
   dass der Abbau hinter dem neuen Mount landet. Der erste Reparaturversuch
   scheiterte dadurch regelmaessig - und der zweite kostete 30 s mount-Timeout
   plus Pruefungen. Jetzt werden 1,5 s auf den Abbau gewartet, bevor neu
   gemountet wird; die Wache prueft erstmals nach 3 s statt 10 s und benutzt zum
   ERKENNEN die einfache schnelle Probe (die Doppelprobe steckt dort, wo der
   Wettlauf lauert: direkt nach dem Mount).

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

docker/api/main.py

@@ -401,9 +401,9 @@ ROHDATEN_INTERVALL_SEKUNDEN = 30
 # Das strukturell zu lösen (Mount auf dem HOST statt im Container) wäre ein
 # eigener Umbau und widerspräche „Speicherziele über das UI einhängen".
 MOUNT_WACHE_INTERVALL_SEKUNDEN = 60
-# Erste Prüfung schon nach zehn Sekunden: Genau dann ist die Lage nach einem
-# Deploy kaputt, und ein Fenster von einer Minute wäre unnötig lang.
-MOUNT_WACHE_ERSTE_PRUEFUNG_SEKUNDEN = 10
+# Erste Prüfung fast sofort: Genau nach einem Deploy ist die Lage kaputt, und
+# jede Sekunde Wartezeit ist eine Sekunde, in der Rippy sein Ziel nicht sieht.
+MOUNT_WACHE_ERSTE_PRUEFUNG_SEKUNDEN = 3
 _MOUNT_STAND = {}
 
 
@@ -430,9 +430,12 @@ def _mounts_nachsehen() -> None:
         return
     for eintrag in eintraege:
         name = eintrag["name"]
-        # Zweimal mit Abstand: Nach einem frischen Mount antwortet die Freigabe
-        # einen Moment und stirbt dann wieder (Wettlauf mit dem lazy umount).
-        erreichbar = mount_verwaltung.wirklich_erreichbar(name)
+        # Zum ERKENNEN genügt die einfache, schnelle Probe: Ein toter Mount
+        # antwortet gar nicht, nicht nur manchmal. Die Doppelprobe steckt dort,
+        # wo sie hingehört — in `mounten()`, direkt nach einem frischen Mount, wo
+        # der Wettlauf mit dem lazy umount lauert. Hier kostete sie nur jede
+        # Minute drei Sekunden Warten für nichts.
+        erreichbar = mount_verwaltung.ist_erreichbar(name)
         vorher = _MOUNT_STAND.get(name)
         _MOUNT_STAND[name] = erreichbar
         if erreichbar: