Verwaltung fragt nicht mehr grundlos nach dem Zugangscode

Zwei Ursachen, die zusammenwirkten.

1. Nach einem Neuladen war die HERKUNFT des Schluessels vergessen. Der
   Code speicherte nur den Schluessel selbst, nicht ob er aus einer
   Codeeingabe oder aus dem Ausweis der Zugangswand stammt.

2. Weil die Herkunft fehlte, wurde vorsichtshalber 'code' angenommen.
   Als Vorsicht gedacht, mit unangenehmer Kehrseite: Ein Ausweis gilt nur
   15 Minuten. Als 'code' behandelt wurde er nie erneuert -- nach einer
   Viertelstunde kam der erste 401, und man landete in der Codeeingabe,
   obwohl alles in Ordnung war. Der Schutz 'eine Code-Sitzung wird nie
   durch einen Ausweis ersetzt' war damit ab dem ersten Neuladen ohnehin
   wirkungslos.

Die Herkunft steht jetzt neben dem Schluessel und ueberlebt ein
Neuladen. Fehlt sie -- etwa aus einer aelteren Sitzung --, bleibt es bei
der vorsichtigen Annahme 'code'.

Das behebt die Haelfte des Problems. Die andere Haelfte ist eine
Einstellung auf dem Server: Die beiden Dienste benutzen nicht dasselbe
WEBDESIGN_API_SECRET, weshalb jeder Ausweis abgelehnt wird. Der Kommentar
in server/.env.example sagt ausdruecklich, dass beide Werte exakt gleich
sein muessen. Das kann nur Filipe angleichen -- /home/dogiintern/ ist
fuer claudian gesperrt.

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

webdesign/sw.js

@@ -34,7 +34,7 @@
    Start alle alten Zwischenspeicher weg. Muss bei jeder Änderung an den
    Dateien unten hochgezählt werden, sonst hängen Nutzer auf einem alten
    Stand fest. */
-const CACHE_NAME = "dogfather-webdesign-v23";
+const CACHE_NAME = "dogfather-webdesign-v24";
 
 /* Bausteine, die die Oberfläche zum Anzeigen braucht. Bewusst KEINE
    HTML-Datei in dieser Liste. */