feat: Docker-, Kubernetes- und Gitea-Actions-Deployment-Pipeline

Dockerfile (Multi-Stage, "output: standalone"), docker-compose.yml mit
Caddy als einzigem nach aussen offenem Reverse-Proxy (verhindert
X-Forwarded-For-Faelschung fuer das App-eigene Rate-Limiting), Gitea
Actions Workflow der bei jedem Push zwei Image-Tags in die Gitea-
Container-Registry baut (schlankes Laufzeit-Image + ein Migrations-
Image mit Prisma-CLI), sowie rohe Kubernetes-Manifeste (Namespace,
ConfigMap, Secret-Vorlage, Postgres-/MySQL-StatefulSet, Migrations-Job,
App-Deployment, Ingress) fuer den Cluster-Betrieb. Siehe k8s/README.md
fuer den vollstaendigen Einrichtungs-/Deployment-Ablauf.

Caddyfile

@@ -0,0 +1,18 @@
+{
+	# Fuer eine echte Domain mit automatischem HTTPS: {$SITE_ADDRESS} unten auf
+	# z.B. "wabenhain.com" setzen und diesen Block entfernen. Ohne echte
+	# Domain kann Caddy kein Zertifikat ausstellen, daher hier bewusst
+	# lokal-tauglich per HTTP eingerichtet.
+	auto_https off
+}
+
+{$SITE_ADDRESS::80} {
+	# Terminiert die tatsaechliche Client-Verbindung und ueberschreibt
+	# X-Forwarded-For dabei komplett mit der selbst beobachteten IP (Caddy
+	# verwirft eingehende X-Forwarded-For/-Proto/-Host-Header von Clients
+	# per Default, siehe https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults).
+	# Ohne diesen Proxy koennte jeder Client den Header selbst faelschen und
+	# damit saemtliche Rate-Limits (Login, 2FA, Checkout, ...) umgehen, siehe
+	# lib/rate-limit.ts.
+	reverse_proxy app:3000
+}