GC-Backup: täglicher Scheduler angelegt (vorher gab es keinen)

Diagnose: die GC-Backups standen seit 2026-09-04, weil NIE ein Scheduler
existierte — Backup/Intended/Compliance liefen nur manuell aus Sessions. Die
"2×/Tag per SSH"-Annahme (CLAUDE.md Bot-Master-Zeile + gc-snapshot.py-Docstring)
war nie real; beide korrigiert.

Fix: Nautobot-Job "Execute All Golden Configuration Jobs - Multiple Device"
enabled + ScheduledJob "GC Backup+Compliance – taeglich" (platform=RouterOS,
täglich 03:30 UTC, Backup→Intended→Compliance). Sofort-Lauf SUCCESS, alle 5
Geräte backup/compliance auf 2026-09-12 10:35, frischer bf-golden-config-Commit.
Announcement-Eintrag ergänzt.

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

nautobot/gc-snapshot.py

@@ -13,9 +13,11 @@ Nautobot selbst — es wird KEIN Gerät kontaktiert:
   mgmt_ip             device.primary_ip4 (ohne /prefix)
 
 Warum aus Nautobot statt live vom Gerät: der MGMT-/REST-Weg (VLAN99:80) ist
-nicht aus jedem Vantage erreichbar; die GC-Backups werden ohnehin 2×/Tag per
-SSH gezogen und sind die Doku-SSoT. Damit ist der Snapshot cron-fest und
-braucht keine Geräte-Credentials. Aktualität steht in `backup_last_success_date`.
+nicht aus jedem Vantage erreichbar; die GC-Backups werden täglich (03:30 UTC,
+ScheduledJob "GC Backup+Compliance – taeglich") per SSH gezogen und sind die
+Doku-SSoT. Damit braucht der Snapshot keine Geräte-Credentials. Aktualität steht
+in `backup_last_success_date` — ist die alt, steht der Backup-Schedule (2026-09-12
+war er 8 Tage aus, weil es vorher gar keinen gab).
 
 Der Backup-Config-Text wird nur INTERN geparst (Zähler/Modus abgeleitet) und
 NIE ausgegeben — er kann gescrubte Reste enthalten (PSK-Leak-Regel).