deploy-kit zum Gitea-Template-Repo umbauen

Statt eines zweiten Repos wird deploy-kit selbst die Vorlage. Ein Template
kopiert das gesamte Repo, die Projektdateien muessen also im Wurzel-
verzeichnis liegen - template/ ist entsprechend aufgeloest.

- bootstrap.sh entfaellt: das Template uebernimmt seine Aufgabe, und
  Gitea kopiert serverseitig, funktioniert also auch bei privatem Repo.
- .gitea/template laesst Gitea ${REPO_NAME} in README.md und
  docker-compose.yml ersetzen. Projektname, Image und container_name
  stimmen damit ohne Handarbeit, offen bleibt nur der Port.
- CLAUDE.md zeigt auf DEPLOY.md, damit die Konventionen beim Arbeiten am
  erzeugten Projekt gelesen werden.
- DEPLOY.md liegt jetzt nur noch einmal - die Kopie im geplanten zweiten
  Repo waere unweigerlich auseinandergelaufen.

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

CLAUDE.md

@@ -0,0 +1,24 @@
+# Projekthinweise
+
+## Deployment
+
+Diese App wird per Tag-Push deployt, nicht manuell hochgeladen.
+Die verbindlichen Konventionen stehen in **DEPLOY.md**. Vor Aenderungen an
+`Dockerfile`, `docker-compose.yml` oder `.gitea/workflows/` dort nachsehen.
+
+Kurzfassung der Regeln, die man leicht bricht:
+
+- Kein `ports:` im Compose. Der Proxy erreicht den Container ueber das Netz
+  `nginx-proxy-manager_default` unter seinem `container_name`.
+- `name:` im Compose ist Pflicht (fester Projektname), sonst legt der
+  CI-Job einen zweiten Stack an.
+- Keine relativen Bind-Mounts. Compose laeuft im Job-Container, der Pfad
+  zeigt auf dem Host ins Leere. Persistente Daten in named volumes mit
+  festem `name:`.
+- Healthcheck ist Pflicht, der Deploy nutzt ihn als Gate.
+- Secrets kommen aus dem Repo-Secret `DOTENV`, nie in die Compose-Datei.
+
+## Noch offen in diesem Repo
+
+Nach dem Anlegen aus der Vorlage sind `__APP__` und `__PORT__` zu ersetzen
+und das Dockerfile an den Stack anzupassen. Details in README.md.