Repo-Backups, Gitea-Theme und Auto-Deploy

- Repo-Backups: nachts um 04:00 werden alle Gitea-Repos als git-Bundle
  gesichert — eine Datei pro Repo mit kompletter Historie, aus der sich
  direkt wieder klonen lässt. 14 Tage Rotation wie beim DB-Backup,
  Schalter und "Repos jetzt sichern" im System-Tab. Nutzt den bereits
  vorhandenen Gitea-Token; Dockerfile installiert dafür git mit.
- Gitea-Theme im D4RKST3R-Look (docs/gitea-theme/): Neon-Gelb/Orange auf
  Schwarz, gebaut gegen die Variablen von Gitea 1.26, Diff-Farben bleiben
  lesbar. Einbau-Anleitung liegt daneben.
- Auto-Deploy statt manuellem "Pull and redeploy": Workflow für Gitea
  Actions (prüft Server-Syntax und Frontend-Build, bevor deployed wird)
  plus dokumentierter Runner-loser Weg über den Portainer-Webhook.

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

docs/auto-deploy.md

@@ -0,0 +1,71 @@
+# Auto-Deploy statt „Pull and redeploy"
+
+Bisher: pushen, in Portainer einloggen, Stack suchen, *Pull and redeploy* klicken.
+Das geht automatisch — zwei Wege, je nachdem wie viel du willst.
+
+## Weg 1: Portainer-Webhook (2 Minuten, kein Runner nötig) ← empfohlen
+
+Portainer kann einen Stack per HTTP-Aufruf neu ausrollen. Gitea ruft diese
+Adresse nach jedem Push auf, fertig.
+
+**In Portainer:**
+
+1. Stack `ecobot` öffnen → Reiter **Editor**
+2. **Automatic updates** einschalten, Methode **Webhook**
+3. Die erzeugte Webhook-URL kopieren
+   (Form: `https://portainer.../api/stacks/webhooks/<uuid>`)
+
+**In Gitea:**
+
+1. Repo `d4rkbot` → **Einstellungen → Webhooks → Webhook hinzufügen → Gitea**
+2. Ziel-URL: die kopierte Portainer-Adresse
+3. HTTP-Methode `POST`, Inhaltstyp `application/json`
+4. Trigger: **Push-Ereignisse**, Branch-Filter `main`
+5. Speichern, dann **Zustellung testen** — Portainer sollte den Stack neu bauen
+
+> Der Stack muss aus dem Git-Repository deployed sein (nicht aus einem
+> hochgeladenen Compose-Text), damit Portainer den neuen Stand ziehen kann.
+> „Re-pull image" bleibt **aus** — das Image wird ja lokal gebaut.
+
+## Weg 2: Gitea Actions (prüft den Code vor dem Deploy)
+
+Der Workflow in `.gitea/workflows/deploy.yml` installiert die Abhängigkeiten,
+prüft alle Server-Dateien auf Syntaxfehler, baut das Frontend — und stößt erst
+dann das Redeploy an. Kaputter Code geht damit gar nicht erst live.
+
+**Voraussetzung: ein Act-Runner.** In deiner Instanz sind Actions aktiviert,
+aber ohne Runner passiert nichts. Einrichten als zusätzlicher Container:
+
+```yaml
+# docker-compose.yml für den Runner
+services:
+  runner:
+    image: gitea/act_runner:latest
+    restart: always
+    environment:
+      GITEA_INSTANCE_URL: https://git.d4rkst3r.de
+      GITEA_RUNNER_REGISTRATION_TOKEN: <Token aus Gitea>
+      GITEA_RUNNER_NAME: d4rk-runner
+      GITEA_RUNNER_LABELS: ubuntu-latest:docker://node:22-bookworm
+    volumes:
+      - /var/run/docker.sock:/var/run/docker.sock
+      - ./runner-data:/data
+```
+
+Den Registrierungs-Token findest du unter **Site-Administration → Actions →
+Runner → Runner erstellen** (oder pro Repo unter *Einstellungen → Actions*).
+
+**Secret hinterlegen:** Repo → *Einstellungen → Actions → Secrets* →
+`PORTAINER_WEBHOOK` mit der Portainer-Adresse. Fehlt das Secret, läuft nur die
+Prüfung und der Deploy-Schritt wird übersprungen.
+
+## Welchen nehmen?
+
+| | Weg 1 (Webhook) | Weg 2 (Actions) |
+|---|---|---|
+| Aufwand | 2 Minuten | Runner-Container aufsetzen |
+| Prüft den Code | nein | ja (Syntax + Frontend-Build) |
+| Läuft ohne Zusatzdienst | ja | nein |
+
+Fang mit Weg 1 an. Weg 2 lohnt sich, sobald du Tests hast oder mehrere Leute
+pushen — dann verhindert er, dass ein kaputter Stand live geht.