docs(issues): close #0025 — CVE alert deploy is live and verified

The handover issue still sat in waiting while the deploy had long landed:
ff87cb2 is an ancestor of HEAD (CFGMON now runs e9c13dc), the rules aggregate
per image so the per-CVE flood is structurally impossible, matrix-alerts.py
saves state incrementally inside the send loop, and notifications_failed_total
is 0 across 80 series. The null-receiver kill switch is gone.

Recorded honestly what was not observed: whether aggregated messages actually
arrived in the security room once. Delivery is now permanently monitored via
AlertDeliveryFailing, so a future failure reports itself instead of relying on
someone looking.

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

docs/issues/0025-deploy-uebergabe-cve-alarme-aggregiert-receiver.md

@@ -1,14 +1,13 @@
 ---
 type: issue
 id: "0025"
-status: waiting
+status: done
 created: 2026-08-01
 milestone: M1
 priority: medium
 area: infrastructure
-wartegrund: Grund im GitLab-Verlauf benannt (Import 2026-08-11); im nächsten Refinement präzisieren
 gitlab_iid: "25"
-related: []
+related: [docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md]
 ---
 # Deploy-Übergabe: CVE-Alarme aggregiert + Receiver-Robustheit (gitops#51, ff87cb2)
 
@@ -49,3 +48,36 @@ Außenwirkung: nur der Security-Matrix-Raum (interner Kreis). **Not-Aus:** in `m
 ---
 *Migriert aus Gitea `sorb/management#1` (Gitea-Tracker stillgelegt, ADR-0002) — dort erstellt am 2026-08-01 von sorb.*
 <!-- gitea-migration: sorb/management#1 -->
+
+## Erledigt 2026-08-15 — Deploy ist gelandet und nachweislich in Betrieb
+
+Beim Ausbau der Backup-Alarme (#0030) fiel auf, dass dieses Übergabe-Issue noch `waiting`
+stand, obwohl der Deploy längst live ist. Nachgeprüft:
+
+| Abnahmekriterium | Nachweis |
+|---|---|
+| Deploy gelandet | `ff87cb2` ist **Vorfahr von HEAD**; CFGMON läuft inzwischen auf `e9c13dc` (zwei Commits darüber hinaus) |
+| Kein Pro-CVE-Verkehr mehr | Regeln lauten `count by (target, target_type, host) (trivy_vuln_info{…})` — eine Alarm-Instanz je Image; die Flut ist **strukturell** ausgeschlossen, nicht bloß gedrosselt |
+| Receiver-Robustheit | `matrix-alerts.py`: `save_state()` steht **inkrementell in der Sende-Schleife** („Teilfortschritt übersteht Fehler/Retry"), plus 1s-Drosselung gegen `rc_message` und Speichern im Fehlerpfad — genau der beschriebene Bug ist behoben |
+| Regel geladen | 14 Regeln evaluieren mit `health=ok` (Stand 2026-08-15) |
+| Keine 502-Retry-Schleife | `alertmanager_notifications_failed_total` = **0** über 80 Serien aller Integrationen |
+| Not-Aus nicht mehr nötig | Die `room="security"`-Route auf den Null-Receiver existiert nicht mehr; `alertmanager.yml` hat nur die Default-Route auf den `matrix`-Receiver |
+
+**Was NICHT direkt beobachtet wurde:** ob im Security-Raum tatsächlich einmal aggregierte
+🔴-Nachrichten eingetrudelt sind (Kriterium 2 der Übergabe, „gezählt ≤ 29"). Das lässt sich
+nur im Raum bzw. in `docker compose logs matrix-alerts` sehen. Der Fehlzähler bei 0 belegt,
+dass **keine Zustellung gescheitert** ist — er belegt nicht, dass welche stattfand.
+
+Das Issue wird trotzdem geschlossen: sein Zweck war die Übergabe eines Deploys, und der ist
+gelandet, robust und ohne die befürchteten Nebenwirkungen. Die Zustellung ist seit
+`e9c13dc` zudem **dauerhaft überwacht** (`AlertDeliveryFailing` auf
+`alertmanager_notifications_failed_total`) — ein künftiger Zustellfehler meldet sich von
+selbst, statt auf eine manuelle Sichtprüfung zu warten.
+
+**Kleiner Folgepunkt (kein Blocker):** Falls `TrivyCriticalVulns` derzeit `inactive` ist,
+obwohl CRITICAL-Funde bekannt sind (#0051), wäre das ein eigener Hinweis — dann kämen die
+`trivy_vuln_info`-Serien nicht (mehr) an. Einmal im Grafana-Dashboard `cve-overview`
+gegenschauen; gehört fachlich zu #0051.
+
+**Weiterhin bewusst offen (aus dem Original):** Grafana-Dashboard als Matrix-Widget im
+Security-Raum — eigener Punkt, war nie Teil dieses Deploys.