Knopf war unlesbar, und der Code wird jetzt bei jedem Schliessen neu verlangt

Zwei Rueckmeldungen vom 22.08.2026, beide behoben und mit Tests abgesichert.

1) "das sieht nicht gut aus" (Bildschirmfoto des Hauptknopfs)
   Ursache: ".wd a" ist Klasse+Element und damit spezifischer als die reine
   Knopfklasse ".wd-btn--haupt". Die Textfarbe des Knopfs wurde dadurch
   ueberstimmt -- hellblaue Schrift auf hellblauem Grund, praktisch
   unlesbar. Derselbe Spezifitaetsfehler wie zuvor bei den Namen auf der
   Zugangswand. Fix: ".wd a:not(.wd-btn)" plus zweistufig geschriebene
   Knopfregeln, damit das nicht wieder passieren kann.

2) "das sieht lang gezogen aus"
   Die Pillenform (border-radius 999px) laesst breite Knoepfe
   auseinandergezogen wirken, weil der Radius optisch mit der Breite
   mitwaechst. Jetzt fester Radius von 14px -- gleiche Form bei jeder
   Breite, ruhiger und hochwertiger.

3) "ich will das ich jedes mal den code gefragt werde wenn man die seite
   zu macht"
   Das Sitzungs-Cookie allein reicht dafuer nicht: Browser stellen genau
   solche Cookies beim Wiederherstellen von Tabs zurueck ("Dort
   fortfahren, wo du aufgehoert hast"), man landet dann ohne Codeabfrage
   wieder mitten in der Seite. Zusaetzlich jetzt eine Sitzungsmarke im
   sessionStorage, die beim echten Schliessen verschwindet. Fehlt sie bei
   vorhandenem Cookie, wird die Sitzung serverseitig beendet und zur
   Zugangswand geleitet. Token-Notbremse von 24 auf 8 Stunden gesenkt.
   13/13 Tests im echten Browser, inklusive Schutz vor Endlosschleife.

DEPLOY.md: zwei Checkouts auf dem Server dokumentiert (/home/dogiweb und
/home/dogiintern) und der Vorfall, dass /webdesign nach dem Pull kurz ohne
Zugangsschutz erreichbar war, weil der Dienstneustart fehlte.

Co-Authored-By: Claude Opus 5 <[email protected]>

DEPLOY.md

@@ -36,11 +36,53 @@ ssh dogfather-server "cd /home/dogiweb/dogfather-universe && git pull --ff-only
 Statische Dateien (HTML/CSS/JS/Bilder) sind damit **sofort** live — der Express-Dienst liefert
 das Verzeichnis direkt aus, ein Neustart ist dafür **nicht** nötig.
 
-Nur wenn Server-Code geändert wurde (`server/`, `server-internal/`):
+## ⚠️ ES GIBT ZWEI CHECKOUTS AUF DEM SERVER, NICHT EINEN
+
+Am 22.08.2026 beim Ausrollen des Webdesign-Bereichs gefunden — diese Datei
+beschrieb vorher nur den ersten und war damit unvollständig:
+
+| Dienst | Checkout | Liefert |
+|---|---|---|
+| `dogiweb.service` (Port 4100) | `/home/dogiweb/dogfather-universe/` | die öffentliche Website + `server/` |
+| `dogiintern.service` (Port 4200) | `/home/dogiintern/dogfather-universe/` | die API unter `postfach.dogfather-universe.com` + `server-internal/` |
+
+**Ein `git pull` in `/home/dogiweb` ändert an `server-internal/` also gar nichts.**
+Wer nur dort zieht und danach `dogiintern.service` neu startet, startet den
+Dienst mit unverändertem Code neu und wundert sich, warum nichts passiert.
+
+`claudian` hat auf `/home/dogiintern/` **keinen Zugriff** (weder lesend noch
+über den begrenzten sudo). Änderungen an `server-internal/` muss deshalb
+Filipe selbst ausrollen:
 
 ```bash
-ssh dogfather-server "sudo systemctl restart dogiweb.service"     # öffentliche Seite
-ssh dogfather-server "sudo systemctl restart dogiintern.service"  # interner Bereich
+sudo -u dogiintern git -C /home/dogiintern/dogfather-universe pull --ff-only origin main
+sudo systemctl restart dogiintern.service
+```
+
+## Server-Code geändert? Dann ist ein Neustart PFLICHT
+
+Statische Dateien sind nach dem Pull sofort live. Server-Code **nicht** —
+der läuft weiter mit dem alten Stand, bis der Dienst neu startet.
+
+```bash
+ssh dogfather-server "sudo systemctl restart dogiweb.service"     # nach Änderungen in server/
+ssh dogfather-server "sudo systemctl restart dogiintern.service"  # nach Änderungen in server-internal/
+```
+
+**Warum das hier besonders steht (Vorfall 22.08.2026):** Nach dem Pull des
+Webdesign-Bereichs war `/webdesign/` für einige Minuten **ohne Zugangsschutz
+öffentlich erreichbar** (HTTP 200 statt der Umleitung zur Zugangswand). Die
+HTML-Dateien waren durch den Pull sofort da — die Schranke in
+`server/webdesign-gate.js` lief aber erst nach dem Neustart von
+`dogiweb.service`. Bei einem Bereich, der ausdrücklich nicht öffentlich sein
+soll, ist genau dieses Zeitfenster der gefährliche Teil eines Deploys.
+
+Merksatz: **Erst neu starten, dann „ist live" melden** — und danach mit
+`curl -I` prüfen, dass die Schranke wirklich greift:
+
+```bash
+curl -sI https://dogfather-universe.com/webdesign/ | grep -iE "^location|x-robots-tag"
+# erwartet: location: /webdesign/zugang.html?next=...   und   x-robots-tag: noindex, ...
 ```
 
 **Achtung bei Zweig-Namen:** lokal heißt der Zweig `master`, auf dem Server und in Gitea `main`.