ci: Workflow für node:20-bookworm-Runner, Runner-Stack im Swarm-Muster des bestehenden gitrunner

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

deploy/gitea-runner/README.md

@@ -1,7 +1,14 @@
 # Gitea Actions Runner
 
-1. In Gitea: **cluster-knaster → Einstellungen → Actions → Runner → Neuen Runner erstellen**. Token kopieren. Actions muss für das Repo aktiviert sein.
-2. Auf dem Zielhost: `GITEA_RUNNER_REGISTRATION_TOKEN=<token> docker compose up -d`. Alternativ als Portainer-Stack mit der Variablen.
-3. In Gitea erscheint der Runner mit dem Label `ubuntu-latest`. Die CI (`.gitea/workflows/ci.yml`) läuft beim nächsten Push.
+Auf dem Portainer-Host läuft bereits der Stack `gitrunner`. Das ist ein **Org-Runner**: Er bedient nur Repos der Organisation, nicht `rorapp/cluster-knaster`.
 
-**Sicherheit:** Der Runner hat Zugriff auf den Docker-Socket des Hosts. Deshalb nur auf Repo-Ebene registrieren und keine Workflows aus fremden Forks ausführen. Vorgesehener Platz ist der Infra-LXC des Clusters. Bis der steht, ist ein Übergangshost möglich.
+Dafür gibt es zwei Wege:
+- **A:** Das Repo in die Organisation verschieben. Dann ist kein weiterer Runner nötig.
+- **B:** Einen eigenen, ressourcenbegrenzten Runner auf Repo-Ebene betreiben, mit dem Stack in diesem Ordner. Er folgt dem gleichen Muster wie `gitrunner`: Swarm-Secret für den Token, Swarm-Config, `network: bridge`.
+
+Ablauf für B:
+1. In Gitea **cluster-knaster → Einstellungen → Actions → Runner → Neuen Runner erstellen**. Actions muss für das Repo aktiviert sein.
+2. Swarm-Secret `gitea-runner-knaster-token` mit dem Token und Swarm-Config `gitrunner_knaster_config_v1` aus `config.yaml` anlegen.
+3. Stack `gitrunner-knaster` aus `docker-compose.yml` deployen.
+
+**Sicherheit:** Der Runner hat Zugriff auf den Docker-Socket des Hosts. Deshalb nur auf Repo-Ebene registrieren und keine Workflows aus fremden Forks ausführen. Langfristig zieht der Runner in den Infra-LXC des Clusters um.