Rechtstexte, FinalFlux-Überarbeitung, neue Login-Optik, Konto-Löschung-Fix, BTTF-Farbrelaunch

- Rechtsseiten: Impressum-Platzhalter + echte Nutzungsbedingungen/AGB,
  Datenschutz (DSGVO) und Richtlinien; LegalController/ImpressumController,
  Footer app-weit verlinkt, Seiten als permitAll freigegeben.
- FinalFlux: 28 Themen / ~742 Fragen überarbeitet (plausible Distraktoren statt
  Dummy-Antworten, echte Erklärungen) + echte Lehrtexte je Seite;
  Netzwerktopologien mit Inline-SVG-Diagrammen (Stern/Bus/Ring/Mesh/Baum).
- Login/Registrierung als kombiniertes Dual-Panel (Slide-Overlay + Neon-Hover-
  Button), ausgelagert nach auth.css; Register-Duplikat -> /?registerError.
- Konto löschen repariert: @Transactional + Löschen von Spielständen,
  Achievements und Profilbild-Datei (DSGVO Art. 17). Impressum-Zurück-Link
  login-abhängig.
- App-weiter Farb-Relaunch auf "Back to the Future"-Palette: Feuer-Amber primär
  + Flux-Blau sekundär, warmer Glow; Dark/Light bleiben. Spiele-Feedback ohne
  Grün: richtig = Blau + Haken, falsch = Rot + Kreuz (neue Tokens
  --success/--danger/--secondary). Legacy-Cyan in style.css auf Variablen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

src/main/resources/static/finalflux/systemintegration/thin-client.html

@@ -25,6 +25,52 @@
     </ul>
   </section>
 
+  <section>
+    <h2>Was ist ein Thin Client?</h2>
+    <p>Ein <strong>Thin Client</strong> ist ein bewusst schlank gehaltenes Endgerät, das selbst kaum Rechenleistung besitzt. Tastatur, Maus und Bildschirm werden lokal bedient, doch die eigentlichen Anwendungen laufen auf einem zentralen Server. Der Client überträgt nur Eingaben (Tastatur/Maus) zum Server und erhält im Gegenzug das Bildschirmbild zurück. Man spricht deshalb auch von <em>Server-based Computing</em>.</p>
+    <ul class="key-list">
+      <li>Rechenleistung, Programme und Daten liegen auf dem Server, nicht im Gerät.</li>
+      <li>Das Endgerät benötigt nur schwache, sparsame Hardware und wenig oder keinen lokalen Speicher.</li>
+      <li>Eine ständige Netzwerkverbindung zum Server ist zwingend erforderlich.</li>
+    </ul>
+    <p class="merksatz"><strong>Merksatz:</strong> Beim Thin Client liegt die Intelligenz im Netz - das Gerät ist nur Ein- und Ausgabe.</p>
+  </section>
+
+  <section>
+    <h2>Abgrenzung: Fat Client, Thin Client und Zero Client</h2>
+    <p>Die drei Begriffe unterscheiden sich vor allem darin, <strong>wo die Rechenleistung sitzt</strong>:</p>
+    <ul class="key-list">
+      <li><strong>Fat Client (Thick Client):</strong> Ein vollwertiger PC mit eigener CPU, Speicher und lokal installierter Software. Er arbeitet weitgehend unabhängig vom Server - z. B. ein klassischer Büro- oder CAD-Arbeitsplatz.</li>
+      <li><strong>Thin Client:</strong> Schlankes Gerät mit minimalem Betriebssystem, das Anwendungen per Sitzung vom Server bezieht. Etwas lokale Logik (Verbindungsaufbau, Protokoll) ist vorhanden.</li>
+      <li><strong>Zero Client:</strong> Noch reduzierter - praktisch ohne Betriebssystem und Konfiguration. Er stellt nur das Server-Bild dar und verbindet sich fest auf ein Protokoll. Wartung und Angriffsfläche sind dadurch minimal.</li>
+    </ul>
+    <p>Faustregel: Je „dünner" der Client, desto mehr verlagert sich die Arbeit auf den Server und desto stärker steigt die Abhängigkeit von Server und Netzwerk.</p>
+  </section>
+
+  <section>
+    <h2>Server-based Computing und Terminalserver</h2>
+    <p>Die Grundlage für Thin Clients ist das <strong>Server-based Computing</strong>: Ein leistungsstarker <strong>Terminalserver</strong> (z. B. mit Remote Desktop Services oder einer VDI-/Virtualisierungslösung) stellt vielen Nutzern gleichzeitig Desktops oder einzelne Anwendungen bereit. Jeder Nutzer arbeitet in einer eigenen Sitzung, die über ein Übertragungsprotokoll (z. B. RDP) an seinen Thin Client gesendet wird.</p>
+    <ul class="key-list">
+      <li>Software wird einmal zentral installiert und gepflegt - alle Nutzer profitieren sofort.</li>
+      <li>Benutzerprofile liegen serverseitig: Der Nutzer findet seine Umgebung an jedem Client wieder.</li>
+      <li>Der Server muss ausreichend dimensioniert und möglichst ausfallsicher (redundant) sein.</li>
+    </ul>
+  </section>
+
+  <section>
+    <h2>Vor- und Nachteile in der Praxis</h2>
+    <p>In AP1-Aufgaben sollst du Thin Clients gegen die Anforderungen eines Szenarios abwägen. Die wichtigsten Punkte:</p>
+    <ul class="key-list">
+      <li><strong>Administration:</strong> Vorteil - zentrale Verwaltung, einfacher Rollout über Images, schnelle Skalierung, weniger Wartung am Endgerät.</li>
+      <li><strong>Sicherheit/Datenschutz:</strong> Vorteil - Daten bleiben zentral, ein gestohlenes Gerät enthält keine sensiblen Informationen, einheitliche Zugriffskontrolle.</li>
+      <li><strong>Kosten:</strong> Gemischt - günstige Endgeräte und geringer Stromverbrauch, aber teure und leistungsfähige Serverinfrastruktur. Entscheidend sind die Gesamtkosten (TCO).</li>
+      <li><strong>Lokale Leistung:</strong> Nachteil - rechen- oder grafikintensive Anwendungen (z. B. CAD, Video, 3D) eignen sich schlecht; hier sind Fat Clients oft besser.</li>
+      <li><strong>Abhängigkeit von Netz und Server:</strong> Nachteil - ohne stabiles Netzwerk und laufenden Server kein Arbeiten; der Server wird zum Single Point of Failure, hohe Latenz stört die Bedienung.</li>
+    </ul>
+    <p><strong>Typische Einsatzfälle:</strong> Callcenter, Schulungsräume, Verwaltung oder Schalterarbeitsplätze - überall dort, wo viele gleichartige Arbeitsplätze mit standardisierter Software benötigt werden.</p>
+    <p class="merksatz"><strong>Merksatz:</strong> Thin Clients glänzen bei vielen gleichartigen Standardarbeitsplätzen, scheitern aber an hoher lokaler Leistung und fehlender Netzverfügbarkeit.</p>
+  </section>
+
   <section>
     <h2>Prüfungsmodus</h2>
     <p>Dieser FluxCheck führt dich durch die wichtigsten AP1-Aspekte dieses Themas. Du kannst Antworten prüfen, Fragen überspringen und bekommst am Ende eine Auswertung nach Kategorie.</p>