Dashboard hinter Caddy: TLS (100 Jahre selbstsigniert) + eigene Basic-Auth auf Port 443

Stefans Entscheidung: 0.0.0.0-Bind mit unverschluesseltem Basic-Auth war nur
Testzustand. Jetzt bindet hermes-agent-dashboard wieder auf 127.0.0.1, ein
neuer Caddy-Service (network_mode: host) terminiert TLS auf 443 mit einem
manuell erzeugten selbstsignierten Zertifikat (100 Jahre Laufzeit, kein
Let's-Encrypt-Domain-Zwang) und erzwingt eine zweite, eigene Basic-Auth-Schicht
(bcrypt-Hash in CADDY_BASIC_AUTH_HASH, getrennt von Hermes' pbkdf2-Hash) -
noetig weil Hermes' eigenes Auth-Gate laut Fehlermeldung nur bei 0.0.0.0-Binds
"engagiert". README + .env.example um die Setup-Schritte (Cert-Erzeugung,
Caddy-Hash, $-Escaping-Falle) ergaenzt.

Caddyfile

@@ -0,0 +1,26 @@
+# Caddy-Config fuer den Hermes-Dashboard-Reverse-Proxy.
+# Keine Secrets hier drin — Username/Passwort-Hash kommen als {$ENV_VAR}
+# (Caddyfile-Shorthand fuer {env.ENV_VAR}) aus dem Container-Environment,
+# das wiederum aus .env kommt (siehe docker-compose.yml, Service "caddy").
+#
+# TLS: bewusst kein "tls internal" (Caddys eigene interne CA, Zertifikate nur
+# ~12h gueltig, auto-rotiert) und kein Let's Encrypt (braucht oeffentliche
+# Domain + Port 80). Stattdessen ein manuell erzeugtes selbstsigniertes
+# Zertifikat mit 100 Jahren Laufzeit, siehe README fuer den openssl-Befehl.
+# Einmalig im Browser als Sicherheits-Ausnahme akzeptieren, danach nie wieder
+# Renewal-Aerger.
+:443 {
+	tls /certs/dashboard.crt /certs/dashboard.key
+
+	basic_auth {
+		{$HERMES_DASHBOARD_USER} {$CADDY_BASIC_AUTH_HASH}
+	}
+
+	reverse_proxy 127.0.0.1:9119
+}
+
+# Optional-freundlich: wer versehentlich mit http:// statt https:// draufklickt,
+# landet trotzdem verschluesselt statt an "connection refused".
+:80 {
+	redir https://{host}{uri} permanent
+}