docs: the media probe runs monthly, and its failure is provably visible

restore-drill-media, on the 4th at 05:20, an hour after the database
probe. The name is the alerting: BackupJobFailed already matches
restore-drill.*, so a failure needs no new rule and reaches the
maintenance room through the single alertmanager route.

Every link is measured rather than assumed. A control run with a
deliberately damaged file reported one mismatch and failed the job. The
job name was checked against the rule's regex. The route was read from the
config. And delivery works today: seven notifications sent, none failed,
alertmanager up.

The probe re-proves its own comparison on every run: after passing, it
alters one shared file by a byte and fails with "this probe proves
nothing" if the comparison stays quiet. That a comparison has only ever
said "equal" is a guess, and running monthly does not change it.

Silence is covered too - the stale and missing alarms now match the prefix
and name which probe is affected - but those two rule changes sit in
threadnet-operating and are not live: the operating stack does not pull by
itself, and Prometheus still serves the old expressions, measured through
its rules API. The failure alarm is unaffected and already armed. Written
down as open rather than reported as done.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM

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

@@ -391,3 +391,46 @@ dass das Zurückschreiben unter Last funktioniert. Das steht so auch in `restore
 **Vorschlag, nicht umgesetzt:** Diese Probe ließe sich wie `restore-drill` monatlich
 fahren. Sie ist gefahrlos (lesend, `emptyDir`), dauert wenige Minuten und wäre die einzige
 Prüfung, die den Medienpfad überhaupt beobachtet. Entscheidung sorb.
+
+## Nachtrag 2026-08-21 (zweiter Teil) — Medien-Probe automatisiert (Auftrag sorb)
+
+Der Vorschlag von oben ist umgesetzt: **`restore-drill-media`**, monatlich am 4. um 05:20,
+eine Stunde nach der Datenbank-Probe. Eigener CronJob statt Anbau — die Datenbank-Probe
+braucht eine Wegwerf-Postgres, diese das Produktions-PVC (lesend); zwei Rechte- und
+Fehlerbilder in einem Job machen die Fehlersuche im Ernstfall schwerer.
+
+### Fehlschlag ist im Wartungsraum sichtbar — belegt, nicht angenommen
+
+| Glied | Beleg |
+|---|---|
+| Echter Datenschaden lässt den Job scheitern | Kontroll-Lauf mit absichtlich verfälschter Datei: `davon abweichend: 1` → `FEHLER` → `failed=1` |
+| Der Job fällt unter die bestehende Alarmregel | `BackupJobFailed` matcht `restore-drill.*`; `restore-drill-media-…` geprüft |
+| Es gibt genau eine Alertmanager-Route | `receiver: matrix` → wartung-Raum, keine Aufteilung nach `room` mehr |
+| Die Zustellung funktioniert heute | `alertmanager_notifications_total = 7`, `…_failed_total = 0`, `up{job="operating_alertmanager"} = 1` |
+
+**Der Name ist die Alarmierung.** `restore-drill-media` fällt ohne neue Regel unter
+`BackupJobFailed` — deshalb heißt er so und nicht `media-restore-drill`.
+
+### Die Probe beweist bei jedem Lauf ihre eigene Vergleichslogik
+
+Nach dem bestandenen Abgleich verfälscht der Job **eine gemeinsame Datei um ein Byte** und
+verlangt, dass der Vergleich es meldet. Tut er es nicht, scheitert der Lauf mit *„diese
+Probe beweist nichts"*. Ein Abgleich, der nur je „gleich" gesagt hat, ist eine Vermutung —
+und das bleibt wahr, wenn er monatlich statt einmalig läuft.
+
+Erstlauf des ausgerollten CronJobs: `318 Dateien zurueckgespielt, alle gemeinsamen
+byte-gleich, Vergleich gegengeprueft`.
+
+### Auch die Stille ist abgedeckt — aber noch nicht scharf
+
+`RestoreDrillStale` matcht jetzt `restore-drill.*` statt eines festen Namens und nennt die
+betroffene Probe in der Meldung; mit zwei Proben sagt „die Restore-Probe lief nicht" sonst
+nicht, welche. `BackupCronJobMissing` kennt den neuen CronJob, weil eine verschwundene
+Serie in Prometheus kein Alarm ist, sondern Stille.
+
+⚠️ **Offen: Diese beiden Regeländerungen liegen in `threadnet-operating` (`2eec485`),
+laufen aber noch nicht.** Der operating-Stack zieht seine Konfiguration nicht automatisch;
+Prometheus führt weiterhin die alte Fassung — nachgemessen über die Rules-API. **Der
+Fehlschlag-Alarm ist davon nicht betroffen und schon jetzt scharf**, nur die zwei
+Stille-Alarme brauchen ein `git pull` und einen Reload auf dem Host. Seit die Configs als
+Verzeichnis gemountet sind (#0083), genügt dafür ein Reload ohne Neuanlage.