TP45 Schicht A: Nautobot .30/.31/.32/.34 -> .154/.155/.156/.158

Oktett-Klasse .150-.199 (App-Services). Nautobot gibt damit .30/.31 an
AGH frei. .157 ist gitea, deshalb nimmt redis .158.

- Datenmigration ueber neues nautobot/tp45-ip-move.py: Nautobot verbietet
  das Aendern einer IP nach dem Anlegen -> anlegen/primary_ip4 umhaengen/
  Altobjekt loeschen, in dieser Reihenfolge
- Stack-Redeploy (PUT /api/stacks/203), Caddy-Backend, Core-Literal *24
  ueber GC deployt (Plan 51a90e25) mit Wirksamkeitspruefung am Geraet
- caddy/deploy.sh: push_verified() ersetzt den push||push-Fallback.
  `pct push` meldet Exit 0 AUCH wenn es die Quelle nicht lesen kann, der
  Fallback griff deshalb nie und `caddy validate` pruefte die ALTE Datei
  -> gruene Abnahme bei unveraendertem Zustand (Symptom: 502 bei
  gesundem Backend)
- 39 Referenzen in 28 Dateien mitgezogen; lebende Doku nachgezogen
  (CLAUDE.md, ip-plan.md, cf-tunnel-mapping §0-Kopf, TP16.3/TP31-Prosa)
- GC-Compliance 140/140, 0 Drifts

Neue Funde (TP45-Prosa + CLAUDE.md):
- Die Core-Adressliste `nautobot` wird von GC nirgends gerendert -> ein
  Recovery von null erzeugt einen Core, in den Nautobot nicht mehr per
  SSH kommt. Gleiche Klasse wie die fehlenden DHCP-Reservierungen.
- Regel *24 (Literal) und *28 (Liste) sind Dubletten; der Literal steht
  bei 0 Paketen. Zusammenlegung bleibt offen.
- gc-manual-plan.py: /api/extras/job-log-entries/ liefert 404 (Nautobot
  3.x) -> bei gescheitertem Deploy fehlt die Fehlermeldung.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

nautobot/gc-configplan.py

@@ -60,7 +60,7 @@ import urllib.error
 import urllib.parse
 import urllib.request
 
-BASE = "http://10.40.20.30:8080/api"
+BASE = "http://10.40.20.154:8080/api"
 TOKEN = os.environ.get("NAUTOBOT_TOKEN", "")
 
 # Status-UUIDs fuer nautobot_golden_config.configplan (2026-08-16 aus der API gelesen)
@@ -289,7 +289,7 @@ def job_mgmt_acl():
     das ist auf dem Core passiert. Umgekehrt fuhren branch/ap1/ap2 ssh/www/winbox/api/ftp/
     telnet komplett OHNE Address-Beschraenkung; winbox war auf allen vier offen.
 
-    KEIN LOCKOUT-RISIKO: der Deploy laeuft von Nautobot (10.40.20.30) aus, also aus
+    KEIN LOCKOUT-RISIKO: der Deploy laeuft von Nautobot (10.40.20.154) aus, also aus
     10.40.0.0/16 -- die Adresse bleibt in jeder gesetzten ACL enthalten. RouterOS wendet
     `address=` ohnehin erst auf NEUE Verbindungen an, die laufende Session ueberlebt.
 
@@ -360,7 +360,7 @@ def job_tp38_oob():
     * branch: ether23 untaggen, VLAN99 um untagged=ether23 erweitern, 8 Input-Regeln
       (deny-by-default). Die Regeln werden in der Reihenfolge angelegt, in der das
       Template sie rendert — established zuerst, drop zuletzt — damit kein LOCKOUT:
-      die laufende Nautobot-SSH-Session (10.40.20.30) matcht auf Regel 1 (established),
+      die laufende Nautobot-SSH-Session (10.40.20.154) matcht auf Regel 1 (established),
       bevor Regel 8 (drop) greift.
     * core: ether23 untaggen, VLAN99 untagged=ether23, EINE Regel "OOB->core mgmt" mit
       place-before vor die Log-Regel (sonst landet sie hinter dem finalen drop und
@@ -368,7 +368,7 @@ def job_tp38_oob():
 
     KEIN LOCKOUT-RISIKO: ether23 ist auf beiden Geraeten frei (running=false); der
     VLAN99-Umbau aendert nur `untagged`, nicht `tagged`; der Deploy laeuft von Nautobot
-    (10.40.20.30), das in jeder gesetzten Firewall-Freigabe enthalten bleibt.
+    (10.40.20.154), das in jeder gesetzten Firewall-Freigabe enthalten bleibt.
     """
     bridge_set = (
         ':do { /interface bridge port set [find interface=ether23] pvid=99 '