Multi-Tenant-Umschaltung + Pro-Tenant-Vorgaben, RPA deaktiviert

- Multi-Tenant: Settings-Schalter Single/Multi, Profile mit je eigener
  App-Registrierung, Topbar-Umschalter mit Sofort-Reconnect; verlustfreie
  Migration (Get-ActiveConnection/-TenantProfile, /api/tenants[/switch]).
- Pro-Tenant-Overrides mit globalem Fallback: Abteilungs-Praefixe sowie
  Required-/Available-Gruppen-Naming (Get-DepartmentPrefixes/Get-GroupNaming
  tenant-bewusst; New-GroupEndpoint nutzt Resolver).
- RPA komplett deaktiviert: Mode-Tab, globaler Settings-Abschnitt und
  Test-Anzeige entfernt.
- Setup-Zwang gelockert: nur Tenant ID + Client ID Pflicht; Abteilungs-
  Praefixe optional (kein harter Setup-Blocker mehr).
- api(): "Failed to fetch" -> klare Meldung "Server nicht erreichbar…".
- Hilfe-Footer: "Entwickelt von WendeIT – Marco Wende".

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

README.md

@@ -39,6 +39,43 @@ Beenden: `Ctrl+C` im Terminal.
 
 ---
 
+## Single- vs. Multi-Tenant
+
+Unter **Settings → Verbindung → Verbindungsmodus** wählst du zwischen:
+
+| Modus         | Verhalten                                                                 |
+|---------------|---------------------------------------------------------------------------|
+| Single-Tenant | Klassisch: ein Mandant (Tenant ID + App-Registrierung). Standard.         |
+| Multi-Tenant  | Mehrere Mandanten mit **je eigener App-Registrierung**; Umschalten oben rechts |
+
+Im Multi-Tenant-Modus legst du pro Mandant ein Profil an (Bezeichnung, Tenant ID,
+Client-ID Read/Write, optional Client-ID Read-Only). Der **aktive** Mandant ist
+markiert. Über das **Dropdown in der Topbar** wechselst du zwischen den Mandanten —
+der Wechsel trennt die aktuelle Verbindung und verbindet **sofort neu** mit dem
+gewählten Tenant (Login-Prompt erscheint). Alle Caches werden beim Wechsel geleert.
+
+> Die Scopes (RW/RO) gelten **global** für alle Profile. Jeder Mandant benötigt
+> eine eigene App-Registrierung mit denselben delegierten Berechtigungen und
+> (Admin-)Consent im jeweiligen Tenant. Bestehende Single-Tenant-Konfigurationen
+> werden verlustfrei übernommen (Umschalten auf Multi bietet an, das vorhandene
+> Setup als erstes Profil zu übernehmen).
+
+### Pro-Tenant-Vorgaben
+
+Jedes Tenant-Profil kann **eigene Vorgaben** hinterlegen (z. B. Kunde A → `abt-hm-*`,
+Kunde B → `dept-*`):
+
+- **Abteilungs-Präfixe**
+- **Required-Gruppen-Naming** (Präfix/Suffix)
+- **Available-Gruppen-Naming** (Präfix/Suffix)
+
+Bleibt ein Feld **leer, gilt die globale Vorgabe** aus den entsprechenden
+Einstellungs-Abschnitten (bei Naming greift der Fallback pro Feld einzeln). Beim
+Mandantenwechsel werden die Caches geleert, sodass die passenden Vorgaben gegen
+den aktiven Tenant wirken.
+
+---
+
 ## Verbindungsmodus (Read/Write vs. Read-Only)
 
 Der Server probiert beim Verbinden **zuerst die Read/Write-App-ID** (`clientId`).