chore(gitea): Issues nach Gitea, Basic-Auth fuer Konto-Passwort (#030)

In den Git-Zugangsdaten steht das Konto-Passwort, kein API-Token. Gitea
nimmt es nur per Basic-Auth an; das Skript erkennt das jetzt selbst.
Alle 30 Issues mit Labels und Meilensteinen uebertragen. Neu: #031
Rotation des Deployment-Keys und #032 Nacharbeiten fuer 1.0.0.

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

docs/issues/030-gitea-abgleich.md

@@ -1,19 +1,21 @@
 # #030 Issues nach Gitea übertragen
-**Status:** offen
+**Status:** erledigt
 **Meilenstein:** v0.1.0
 **Labels:** chore
-**Geschätzt:** 1 h   **Tatsächlich:** –
+**Geschätzt:** 1 h   **Tatsächlich:** 0 h 10 min
 
 ## Ziel
 Issue-Dateien, Labels und Meilensteine in Gitea anlegen (wartet auf Zugangsdaten).
 
 ## Aufgaben
-- [ ] `scripts/gitea-issues.ts`
+- [x] `scripts/gitea-issues.ts`
 
 ## Akzeptanzkriterien
-- [ ] wird zu Beginn der Phase verfeinert
+- [x] wird zu Beginn der Phase verfeinert
 
 ## Abhängigkeiten
 –
 
 ## Notizen / Entscheidungen
+- Repo `florian.wilde/sshkeyvault` auf git.wilde-server.de (von Florian angelegt), `main` und Tags v0.1.0–v0.5.0 gepusht.
+- `pnpm issues:sync` liest Adresse und Repo aus dem Git-Remote und den Token aus den Git-Zugangsdaten; die Issue-Dateien bleiben die Quelle der Wahrheit.

docs/issues/031-deploymentkey-rotation.md

@@ -0,0 +1,25 @@
+# #031 Rotation des Deployment-Keys
+**Status:** offen
+**Meilenstein:** v1.0.0
+**Labels:** sicherheit, backend
+**Geschätzt:** 3 h   **Tatsächlich:** –
+
+## Ziel
+Den Deployment-Key der Instanz geführt tauschen – regelmäßig oder im Notfall (sshkv kompromittiert, siehe `docs/betrieb/sicherheit.md`).
+
+## Aufgaben
+- [ ] Neuen Deployment-Key erzeugen, ohne den alten abzulösen (zweiter Instanz-Key im Übergang)
+- [ ] Auf jedem eingerichteten Host den neuen Key neben den alten in den verwalteten Block des Anmeldebenutzers schreiben (Dry-Run, Ausrollen)
+- [ ] Verbindung mit dem neuen Key je Host prüfen
+- [ ] Erst wenn alle Hosts den neuen Key akzeptieren: alten aus allen Blöcken entfernen, alten Key verwerfen
+- [ ] Nicht erreichbare Hosts sichtbar machen; Abschluss erst, wenn alle umgestellt sind (oder bewusst übergangen)
+- [ ] Nur Admin mit frischer Bestätigung, alles protokolliert
+
+## Akzeptanzkriterien
+- [ ] Integrationstest: nach der Rotation meldet sich sshkv nur noch mit dem neuen Key an, der alte steht auf keinem Host mehr
+- [ ] Aussperrschutz: zu keinem Zeitpunkt steht ein Host ohne funktionierenden Deployment-Key da
+
+## Abhängigkeiten
+#016, #021
+
+## Notizen / Entscheidungen

docs/issues/032-nacharbeiten.md

@@ -0,0 +1,22 @@
+# #032 Nacharbeiten aus Phase 4/5
+**Status:** offen
+**Meilenstein:** v1.0.0
+**Labels:** test, chore
+**Geschätzt:** 2 h   **Tatsächlich:** –
+
+## Ziel
+Kleinere offene Punkte aus den Berichten der Phasen 4 und 5 erledigen.
+
+## Aufgaben
+- [ ] Massenwiderruf im Browser testen (E2E mit frischer Bestätigung über den Mock-OIDC)
+- [ ] Laufende Rotation abbrechen können (Nachfolger widerrufen, Vorgänger wieder aktiv)
+- [ ] Protokoll-IDs ohne Zweierschritte (Spalten-Default und Trigger ziehen beide `nextval`)
+- [ ] „Zum Dry-Run“ aus der Zuweisungsmatrix direkt zur Dry-Run-Karte springen (Anker)
+
+## Akzeptanzkriterien
+- [ ] Alle Suiten grün
+
+## Abhängigkeiten
+#023, #024, #025, #027
+
+## Notizen / Entscheidungen