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]>

server/webdesign-gate.js

@@ -31,13 +31,22 @@ import { createHmac, timingSafeEqual as cryptoTimingSafeEqual, randomUUID } from
 export const WD_COOKIE = "dogiwd_session";
 export const WD_ROLLE_COOKIE = "dogiwd_rolle";
 
-/* Sitzungsdauer. Bewusst länger als die 12 Stunden im Universe: hier wird
-   inhaltlich gearbeitet (Anfragen prüfen, Texte pflegen), und ein
-   Rauswurf mitten in einer halb ausgefüllten Verwaltungsmaske wäre
-   teurer als das kleine zusätzliche Risiko. Das Cookie selbst bleibt ein
-   reines Sitzungs-Cookie ohne maxAge — beim Schließen des Browsers ist
-   der Zugang trotzdem weg. */
-export const WD_SESSION_STUNDEN = 24;
+/* Sitzungsdauer als NOTBREMSE, nicht als eigentlicher Ablauf.
+   Der Zugang soll bei jedem Schließen der Seite neu abgefragt werden
+   (Wunsch 22.08.2026: "ich will das ich jedes mal den code gefragt werde
+   wenn man die seite zu macht"). Dafür sorgen zwei Dinge zusammen:
+
+     1. Das Cookie ist ein reines Sitzungs-Cookie (kein maxAge/expires) —
+        der Browser wirft es beim Schließen selbst weg.
+     2. Eine Sitzungskennung im Browser-Sitzungsspeicher, die beim
+        Schließen ebenfalls verschwindet (siehe wd-core.js). Nötig, weil
+        viele Browser mit "Tabs wiederherstellen" auch Sitzungs-Cookies
+        zurückholen und Punkt 1 allein dann NICHT greift.
+
+   Diese Stundenzahl ist nur der Fall, dass ein Browser tagelang offen
+   bleibt. Von 24 auf 8 Stunden gesenkt: bleibt ein Gerät unbeaufsichtigt
+   offen liegen, soll der Zugang spätestens nach einem Arbeitstag zu sein. */
+export const WD_SESSION_STUNDEN = 8;
 
 const WD_PRAEFIX = "/webdesign";