docs(issues): #0030 — alerting chain complete and verified end to end

Records the deployed state: fallback expressions, directory mounts (which proved
themselves on the very next rollout, where a SIGHUP reload was genuinely enough),
and alertmanager now scraped so delivery failures are visible. Also notes the
README correction — delivery had not been muted since gitops#51, and docs saying
otherwise would have made a missing alert look expected.

Left open deliberately: TrivyScanStale has the same missing-series gap but no
natural equivalent to kube_cronjob_created, so it needs a decision rather than a
reflex; and phase A/B of the restore drill still needs a throwaway environment.

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

docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md

@@ -274,3 +274,34 @@ sind in der README benannt.
 ⚠️ **Deploy offen:** `4cb9bfb` ist gepusht, aber noch nicht auf CFGMON aktiv — die
 Mount-Änderung greift erst, wenn die Container neu erstellt werden (`docker compose up -d`
 genügt hier, da sich die Service-Definition ändert).
+
+## Endstand Überwachung 2026-08-15 — Kette durchgängig, verifiziert
+
+Drei Commits in `threadnet-operating`, alle live und im Betrieb gegengeprüft:
+
+| Commit | Was | Nachweis |
+|---|---|---|
+| `e0808ba` | Regel-Ausdrücke mit Fallback (`max by` über `… or kube_cronjob_created`) + `BackupCronJobMissing` | 4 Regeln `health=ok`, Fallback liefert Serien statt Leere |
+| `4cb9bfb` | Prometheus/Alertmanager mounten Config-**Verzeichnis** statt Einzeldateien | md5 Host↔Container identisch; beim **nächsten** Rollout genügte erstmals ein echter SIGHUP-Reload — der Fix hat sich sofort bewährt |
+| `e9c13dc` | `operating_alertmanager`-Scrape + `AlertDeliveryFailing`; veraltete README-Passage korrigiert | `up{job="operating_alertmanager"}=1`, 14 Regeln `health=ok`, 80 Serien `alertmanager_notifications_failed_total` (alle 0) |
+
+**Damit ist die Alarmkette lückenlos beobachtet:** Metrik vorhanden (Fallback) → Regel
+evaluiert (`health=ok`) → Zustellung sichtbar (`AlertDeliveryFailing`) → Scrape-Ausfall
+gedeckt (`TargetDown`). `AlertDeliveryFailing` kann selbst nicht an fehlender Serie
+scheitern: der Zähler existiert ab dem ersten Scrape.
+
+**Nebenkorrektur:** Die README behauptete weiterhin, die Alarm-Zustellung sei per
+`room="security"`-Null-Receiver stummgeschaltet. Diese Route existiert seit gitops#51
+nicht mehr — Alarme **werden** zugestellt, auch die neuen Backup-Regeln (kein `room`-Label
+→ Default-Route auf den `matrix`-Receiver). Eine Doku, die fälschlich „ist stummgeschaltet"
+sagt, hätte ein ausbleibendes Signal als bekannt-und-erwartet erscheinen lassen.
+
+### Offen (bewusst nicht reflexhaft gelöst)
+
+- **`TrivyScanStale`** hat dieselbe Lücke wie ursprünglich `RestoreDrillStale`: ein Image,
+  das **nie** erfolgreich gescannt wurde, hat keine Serie, an der `time() - …` hängen
+  könnte, und bleibt still. Anders als dort gibt es **kein natürliches Pendant zu
+  `kube_cronjob_created`** — es bräuchte eine Soll-Liste der erwarteten Images. Das ist eine
+  Entscheidung, kein Handgriff; gehört fachlich zu #0025/CVE-Pipeline.
+- **Phase A/B des Restore-Verfahrens** (Wiederanlauf auf leerem Host, Synapse-Medien) —
+  unverändert offen, braucht eine Wegwerf-Umgebung.