feat(auth): gleitende Sitzung – Frist ab letzter Benutzung statt ab Anmeldung

Marc flog trotz täglicher Nutzung heraus: Die Frist lief ab dem
Anmelden. Ein Ablauf, der den Anwesenden trifft und nicht den
Abwesenden, erkauft keine Sicherheit, sondern nur Ärger.

Jetzt verlängert jeder angemeldete Aufruf die Sitzung – höchstens einmal
pro Stunde, sonst trüge jede Antwort ein Set-Cookie (beim Laden einer
Dateiliste dreißig Stück). Vorgabe 30 Tage ab letzter Benutzung;
bestehende .env-Werte bleiben unangetastet.

security(auth): Frist galt nur im Browser, nicht für die Signatur

Beim Bauen gefunden, war schon vorher drin: NewSessionStore ersetzte
store.Options, ohne store.MaxAge() zu rufen. Die Codecs behielten damit
gorillas Voreinstellung von 30 Tagen. Wirkung: Der Browser warf das
Cookie nach SESSION_MAX_AGE weg – wer den Wert vorher herauskopiert
hatte, konnte ihn 30 Tage lang weiterbenutzen. Wer die Frist kürzte, um
sie zu kürzen, hatte nichts gekürzt.

Mit Test festgehalten, und der Test ist gegengeprüft: Ohne den Aufruf
schlägt er fehl ("abgelaufene Sitzung gilt weiter"), mit ihm läuft er
durch.

Ein Fehler steckte dabei zuerst im Test selbst: gorilla legt die
entschlüsselte Sitzung im Zusammenhang der Anfrage ab. Zweimal dieselbe
Anfrage zu befragen prüfte den Zwischenspeicher, nicht die Frist. Jetzt
baut jede Prüfung eine frische Anfrage.

Live gegengeprüft: Anmeldung setzt das Cookie, drei angemeldete Aufrufe
danach setzen keins (die Bremse greift).

Dazu die gemessenen Leerlaufwerte der Office-Server im README statt der
Zahlen aus deren Dokumentation (Collabora 51 MB, OnlyOffice 396 MB).

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

README.md

@@ -181,6 +181,18 @@ auf, wenn ein Freigabe-Link oder ein OIDC-Rücksprung ins Leere zeigt.
 hier das Falsche, sieht die Anwendung überall die IP des Proxys – Rate-Limit
 und Audit-Log werden damit wertlos, ohne dass irgendetwas nach Fehler aussieht.
 
+**`SESSION_MAX_AGE`** ist die Frist **ab der letzten Benutzung**, nicht ab dem
+Anmelden. Wer die Cloud regelmäßig öffnet, bleibt angemeldet; wer sie 30 Tage
+nicht anfasst, meldet sich neu an. Verlängert wird höchstens einmal pro
+Stunde – sonst trüge jede Antwort ein `Set-Cookie`.
+
+Was das kostet, damit es niemanden überrascht: Ein Cookie, das jemand aus
+einem fremden Browser kopiert, verlängert sich beim Benutzen mit. Es gibt
+keine Sitzungsliste auf dem Server, die man widerrufen könnte – das ist der
+Preis dafür, ohne Sitzungstabelle auszukommen. **Alle** Sitzungen sofort
+beenden heißt: `SESSION_SECRET` ändern und neu starten. Bei einem gemeinsam
+genutzten Rechner ist eine kürzere Frist die bessere Wahl.
+
 **`ADMIN_PASSWORD`** legt beim allerersten Start den Admin an. Danach leeren:
 Das Konto bleibt, das Passwort stünde sonst dauerhaft in einer Datei.
 
@@ -771,8 +783,14 @@ Der Office-Server ist der mit Abstand hungrigste Teil dieser Anlage:
 
 | | Bedarf | Bemerkung |
 |---|---|---|
-| **Collabora (CODE)** | ~1 GB im Leerlauf, +100–200 MB je offenem Dokument | LibreOffice-Kern, startet pro Dokument einen Prozess |
-| **OnlyOffice Docs** | 2 GB Minimum, **4 GB empfohlen**, dazu Swap | bringt eigenes Postgres, RabbitMQ und Node mit |
+| **Collabora (CODE)** | **51 MB im Leerlauf** (gemessen), +100–200 MB je offenem Dokument | LibreOffice-Kern, startet pro Dokument einen Prozess |
+| **OnlyOffice Docs** | **396 MB im Leerlauf** (gemessen), 2 GB Minimum unter Last, **4 GB empfohlen** | bringt eigenes Postgres, RabbitMQ und Node mit |
+
+Die Leerlaufwerte sind auf dieser Anlage nachgemessen und liegen deutlich
+unter dem, was beide Projekte als Mindestbedarf nennen – gemeint ist dort der
+Betrieb *mit* offenen Dokumenten. Zum Abbild auf der Platte: Collabora 1,9 GB,
+OnlyOffice 4,9 GB. Und OnlyOffice zieht nach **jedem** Start für einige
+Minuten einen ganzen Kern, weil es seine eigenen Web-Dateien packt.
 | **Euro-Office** | wie OnlyOffice, Abbild rund 5 GB | derselbe Unterbau |
 
 Dazu kommt, was schon läuft: Postgres, Aether und – nicht unterschätzen – die