chore(env): JWT_EXPIRES_IN 15m + JWT_REFRESH_EXPIRES_IN dokumentieren

Folge-Aufräumen zur Refresh-Cookie-Migration:
- .env.example: JWT_EXPIRES_IN von 7d auf 15m (Access-Token-Lifetime),
  neue JWT_REFRESH_EXPIRES_IN=7d. Kommentar erklärt das Access-/Refresh-
  Pattern (Memory vs. httpOnly-Cookie, transparenter Refresh).
- docker-compose.yml: durchreichen + Default mit 15m statt 7d, plus
  JWT_REFRESH_EXPIRES_IN als neue Variable.

Bestandsinstallationen mit altem JWT_EXPIRES_IN=7d in der .env
funktionieren weiter (die Variable überschreibt den Default), aber bei
neuen Setups ist sofort der Branchenstandard aktiv.

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

.env.example

@@ -36,8 +36,16 @@ DATABASE_URL=mysql://${DB_USER}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME}
 
 # ============== SECURITY ==============
 # JWT-Secret: min. 32 Zeichen. Generieren: openssl rand -hex 64
+# Wird sowohl für Access- als auch Refresh-Token verwendet.
 JWT_SECRET=change-this-to-a-very-long-random-secret-please-rotate-before-production
-JWT_EXPIRES_IN=7d
+
+# Access-/Refresh-Token-Lifetimes
+# - Access-Token: kurzlebig, lebt nur im Browser-Memory (XSS-Schutz)
+# - Refresh-Token: lang, im httpOnly-Cookie (JS-unzugänglich)
+# Wenn der Access abläuft, holt das Frontend transparent einen neuen über
+# /api/auth/refresh – User merkt nichts. Logout invalidiert beide sofort.
+JWT_EXPIRES_IN=15m
+JWT_REFRESH_EXPIRES_IN=7d
 
 # Encryption-Key für Portal-Credentials: GENAU 64 Hex-Zeichen.
 # Generieren: openssl rand -hex 32