Docker: Test-Setup für self-hosted Betrieb (ohne Änderung des App-Teils)

Neuer Ordner docker/ (Dockerfile, docker-entrypoint.sh, docker-compose.yml, README).
Der bestehende App-/Client-Teil (Start.ps1, src/, www/) bleibt unverändert und wird
nur ins Image kopiert. Container-Spezifika laufen ohne Codeeingriff:
- socat-Bridge 0.0.0.0:8080 -> 127.0.0.1:8077 (App bindet weiter nur loopback)
- Datenpfad via XDG_CONFIG_HOME=/data (Volume) - Get-AppDataDir nutzt das auf Linux
- Login über den vorhandenen Device-Code-Flow (WAM/Loopback geht im Container nicht)
Kein Caddy: der vorhandene Reverse-Proxy zieht Port 8080 an.

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

docker/README.md

@@ -0,0 +1,74 @@
+# Intune Manager - Docker-Test (self-hosted)
+
+Test-Aufbau, um den Intune Manager als Container zu verproben. **Der bestehende
+App-/Client-Teil (`Start.ps1`, `src/`, `www/`) wird nicht verändert** — er wird nur
+unverändert ins Image kopiert. Container-Spezifika laufen über Env-Variablen und ein
+Entrypoint-Script.
+
+> Kein Caddy/TLS enthalten — der **vorhandene Reverse-Proxy** zieht den
+> veröffentlichten Port (`8080`) an. HTTPS macht der Proxy.
+
+## Wie es funktioniert
+- Die App bindet unverändert auf `http://localhost:8077/` (nur containerintern).
+- Ein **socat-Bridge** im Container leitet `0.0.0.0:8080 → 127.0.0.1:8077` — dadurch ist
+  die App von außen erreichbar, ohne den App-Code anzufassen.
+- Settings/Policy-Exporte liegen im Volume `/data` (`XDG_CONFIG_HOME=/data`, wird von
+  `Get-AppDataDir` auf Linux automatisch genutzt).
+
+## Bauen & starten
+```bash
+docker compose -f docker/docker-compose.yml up --build -d
+```
+Logs ansehen:
+```bash
+docker compose -f docker/docker-compose.yml logs -f
+```
+Erwartet: „Intune Manager - Web Edition" und „URL: http://localhost:8077/".
+
+Den Reverse-Proxy auf `http://<docker-host>:8080` zeigen lassen (reiner HTTP-Proxy,
+keine WebSockets/Callbacks nötig).
+
+## Erststart: Verbindung konfigurieren
+Beim ersten Start ist noch kein Tenant hinterlegt. Zwei Wege:
+
+- **UI:** Seite öffnen → *Einstellungen* → **Tenant-ID**, **Client-ID** (Read/Write),
+  optional **Client-ID (Read-Only)** und **Scopes** eintragen und speichern. Landet in
+  `/data/IntuneAppManager-Web/settings.json`.
+- **oder** eine vorhandene `settings.json` ins Volume legen:
+  ```bash
+  docker cp settings.json intune-manager-test:/data/IntuneAppManager-Web/settings.json
+  docker compose -f docker/docker-compose.yml restart
+  ```
+
+## Login (Device-Code)
+Der interaktive „Verbinden"-Button nutzt WAM/Loopback und **funktioniert im Container
+nicht** — das ist erwartet. Für den Test den bereits vorhandenen **Device-Code-Flow**
+per `curl` anstoßen (Host = euer Reverse-Proxy oder `http://<docker-host>:8080`):
+
+```bash
+curl -s -X POST http://<host>/api/connect/start
+```
+Antwort enthält `code` und `urlComplete`. Dann:
+1. `urlComplete` im Browser öffnen und als Admin anmelden.
+2. Status pollen, bis verbunden:
+   ```bash
+   curl -s http://<host>/api/status
+   ```
+   (Feld `connected` wird `true`.)
+3. Die UI im Browser **neu laden** → jetzt verbunden. Geräte/Gruppen/Policies laden
+   zum Verifizieren.
+
+## Stoppen / Aufräumen
+```bash
+docker compose -f docker/docker-compose.yml down          # Daten bleiben im Volume
+docker compose -f docker/docker-compose.yml down -v       # inkl. Daten löschen
+```
+
+## Wichtige Hinweise (für den echten Einsatz)
+- **Kein eigener UI-Login und geteilte Sitzung:** Wer die URL erreicht, kann den Login
+  auslösen; die verbundene Graph-Sitzung gilt prozessweit. Die Instanz **zwingend hinter
+  Zugangsschutz** stellen (Reverse-Proxy-Auth / Netzsegment / VPN). Eine Instanz =
+  eine Team-Sitzung, kein sauberes Multi-Admin.
+- Reports liegen unter `/tmp` (nicht persistent) — für den Test ausreichend.
+- Das ist ein **Test-Setup**. Echtes Mehrbenutzer (Login pro Admin) wäre ein separater
+  Ausbau (Auth-Code-Flow + Sitzungs-Isolation).