Initial commit: epaper-dashboard for 7.3" ACeP 7-Color display

- dashboard.py: plugin-based renderer with 4x4 grid layout
- admin.py: web UI with layout editor + plugin configs
- layout.py: pack algorithm, item placement, grid system
- plugins/: clock, weather, system, spotify, strava, gmail, minimax, hello
- network_watchdog.py: WiFi AP/client mode management
- waveshare_epd_init.py: vendor driver stub

RECOVERY.md

@@ -0,0 +1,41 @@
+# Recovery wenn der Pi nicht mehr per SSH erreichbar ist
+
+## Was passiert ist
+- Auf dem Pi lief ein WLAN mit SSID `IoT`, Profil-Name `netplan-wlan0-IoT`
+- Recovery-AP-Test über `nmcli device wifi hotspot` hat einen WLAN-Hotspot `epaper-test` gestartet
+- Dies hat wahrscheinlich die WLAN-Verbindung zum Heimnetz unterbrochen
+- SSH-Connect zum Pi schlägt jetzt fehl (Timeout)
+
+## Sofortige Hilfe
+
+### Option A: Strom-Reset
+1. Pi vom Strom trennen
+2. 10 Sekunden warten
+3. Strom wieder rein
+4. Pi bootet → NetworkManager verbindet sich automatisch mit `IoT` (sofern in Reichweite)
+5. Nach ~60 Sekunden: `ssh koptikp@10.11.3.144` sollte wieder gehen
+
+### Option B: Recovery-Hotspot
+Falls Strom-Reset nicht hilft (z.B. weil Profil `netplan-wlan0-IoT` kaputt ist):
+1. Auf dem Laptop WLAN-Liste scannen
+2. `epaper-recovery` suchen (Passwort `recovery1234`) — falls der Pi im Recovery-Modus ist
+   oder
+3. `epaper-test` suchen (Passwort `test1234`) — falls der Test-Hotspot noch läuft
+4. Verbinden, dann im Browser http://10.42.0.1:8080
+5. Bei Auth-Prompt: `admin:changeme123` (oder `admin:admin`)
+6. Im Netzwerk-Panel: WLAN neu konfigurieren oder "Force AP Mode" / "Disconnect"
+
+### Option C: Tastatur + Monitor
+1. HDMI + USB-Tastatur an den Pi
+2. Anmelden als `koptikp`
+3. `sudo nmcli connection show` → sehen was aktiv ist
+4. `sudo nmcli connection down epaper-test` (oder welcher Müll-Profile da sind)
+5. `sudo nmcli connection delete epaper-test`
+6. `sudo nmcli connection up netplan-wlan0-IoT`
+7. `sudo reboot`
+
+## Was ich anders machen würde
+- **Hotspot-Tests nie** auf einem produktiven Pi laufen lassen, ohne physischen Zugang als Fallback zu haben
+- Watchdog-Code war korrekt; das Problem ist die PolicyKit-Konfiguration
+- Polkit-Restart nach Rule-Update: besser nur `polkitd` SIGHUP schicken, nicht systemctl restart
+  (das hat in dieser Session offenbar den Polkit-Daemon in einem inkonsistenten Zustand hinterlassen)