Overhaul deployment to Gitea Actions CI/CD, remove update.sh

Production no longer builds from source or self-updates via cron/git pull:
setup.sh now only provisions the server once (Docker, /opt/anouma, a
restricted `anouma-deploy` SSH user whose key can only ever run
deploy.sh, generated secrets). All future deployments run through
.gitea/workflows/ci.yml (lint/typecheck/test/build on every push) and
release.yml (on a vX.Y.Z tag: build the image, push it to the Gitea
registry, then SSH-trigger deploy.sh on the server), which pulls,
migrates, restarts, healthchecks, backs up the database first, and
automatically rolls back the code on a failed healthcheck.

docker-compose.yml's app service now runs a registry image
(${ANOUMA_IMAGE}) instead of building locally.

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

README.md

@@ -40,19 +40,26 @@ Der Versand ist idempotent (`reminder60Sent`/`reminder30Sent` je Anmeldung, `hos
 
 ## Setup (Produktion / Deployment)
 
-Der empfohlene Weg ist vollständig dockerisiert und braucht auf dem Host weder Node noch npm:
+Produktion läuft komplett über Gitea Actions CI/CD — der Server baut nichts selbst, er zieht ein fertiges, getestetes Image aus der Registry. Einmalig auf dem Server:
 
 ```bash
 git clone https://git.maro.run/maro/anouma.git
 cd anouma
+chmod +x setup.sh
 ./setup.sh
 ```
 
-`setup.sh` fragt interaktiv nach Domain, ob eine bestehende Nginx Proxy Manager-Instanz eingebunden werden soll usw., generiert fehlende Secrets automatisch und überschreibt nie bereits gesetzte. Baut Images, startet Postgres, wartet auf dessen Healthcheck, migriert, seedet optional die Inhalte und startet die App. `./setup.sh --non-interactive` läuft ohne Rückfragen mit sinnvollen Defaults.
+`setup.sh` installiert bei Bedarf Docker, legt `/opt/anouma` an, generiert alle Secrets automatisch (nie erneut, wenn schon vorhanden), richtet einen eingeschränkten Deployment-User samt SSH-Key für Gitea Actions ein und zeigt am Ende genau die Werte an, die als Gitea Secrets hinterlegt werden müssen. `./setup.sh --non-interactive` läuft ohne Rückfragen.
 
-Updates auf ein neues Release: `./update.sh` (nur echte Release-Tags, nie ungetaggte `main`-Commits; Backup vor jedem Update, automatischer Rollback bei fehlgeschlagenem Healthcheck).
+Jedes weitere Deployment läuft danach ausschließlich über einen Git-Tag:
 
-Für alle Details (NPM-Reverse-Proxy-Einrichtung, Environment-Variablen, WebRTC/STUN/TURN, Backups, Rollback, Auto-Updates, Troubleshooting) siehe **[DEPLOYMENT.md](./DEPLOYMENT.md)**.
+```bash
+git tag v1.2.0 && git push origin v1.2.0
+```
+
+Gitea Actions testet, baut das Image, pusht es in die Registry und deployt es per SSH auf den Server — inklusive Backup, Healthcheck und automatischem Rollback bei Fehlschlag. Es gibt kein separates Update-Script.
+
+Für alle Details (Architektur, Gitea Secrets, CI/Release-Workflows, NPM-Reverse-Proxy-Einrichtung, Environment-Variablen, WebRTC/STUN/TURN, Backups, Rollback, Security) siehe **[DEPLOYMENT.md](./DEPLOYMENT.md)**.
 
 ## Lokale Entwicklung (ohne Docker für die App)
 
@@ -107,6 +114,8 @@ Für einen vollständig dockerisierten Produktionsbetrieb (App + Datenbank, Heal
 | `npm run generate:importmap`| Admin-Importmap neu erzeugen (nach neuen Feldtypen)  |
 | `npm run migrate:create`    | Neue Datenbank-Migration aus Config-Änderungen bauen |
 | `npm run lint`               | ESLint                                              |
+| `npm test`                    | Test-Suite (aktuell ein Platzhalter — noch keine Tests vorhanden) |
+| `npm run seo:check`          | Optionale SEO-Prüfung (doppelte Slugs, fehlende Alt-Texte) — nicht produktionskritisch |
 
 ## Design