Vier gestoppte Gaeste abgeraeumt: 103, 109, 115, 201

User-Entscheid. minarca, node-red, hms-mqtt-publisher und openproject
zerstoert, 28 PBS-Snapshots geloescht, 0 Fehler. Gegenprobe direkt am
Datastore: keine Spur von ct/103|109|115|201 mehr.

Ergebnis: auf pve laeuft jetzt jeder existierende Gast -- 11 LXC + 2 VMs,
kein einziger stopped. Der Datastore enthaelt nur noch aktuelle Gaeste.

Merkregel mitgeschrieben: die Snapshot-Liste VOR dem pct destroy
einsammeln. pvesm list --vmid liefert danach 0, obwohl die Backups noch
liegen -- der Filter braucht die Gast-Config. Genau deshalb lief der
104er-Loeschversuch vorhin ins Leere.

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

docs/handoff-20260825-agh-dns-cutover.md

@@ -29,9 +29,14 @@ Auflösung selbst das Kaputte ist. **Nicht ans Ende einer langen Sitzung legen**
   `http/config/promote` in die Trusted-Liste gekommen und als `stable` bestätigt. Details in TP31.
   ⇒ **Damit ist die CNAME-Umstellung von `hass` nicht mehr blockiert.**
 - ✅ **Aufgeräumt** (TP31 Schritt 1): LXC `120/121/128/129/130(alt)/131` **und `104`** zerstört,
-  72/72 PBS-Snapshots weg — **`ct/104` inzwischen ebenfalls auf 0** (User-Entscheid 2026-08-25).
-  ⚠️ Gegenprobe dafür **direkt am Datastore**, nicht über `pvesm list --vmid`: dessen Filter ist nach
-  einem `pct destroy` nicht mehr aussagekräftig.
+  72/72 PBS-Snapshots weg — **`ct/104` ebenfalls auf 0**, und am selben Abend die vier gestoppten
+  Gäste **`103 minarca`, `109 node-red`, `115 hms-mqtt-publisher`, `201 openproject`** samt ihren
+  **28 Snapshots** (User-Entscheid 2026-08-25).
+  🎯 **Ergebnis: auf pve läuft jetzt jeder existierende Gast** — 11 LXC + 2 VMs, kein einziger
+  `stopped`. Der PBS-Datastore enthält nur noch aktuelle Gäste.
+  ⚠️ **Reihenfolge dabei ist kein Detail:** die Snapshot-Liste **vor** dem `pct destroy` einsammeln.
+  `pvesm list --vmid <id>` liefert danach 0, obwohl die Backups noch liegen — der Filter braucht die
+  Gast-Config. Gegenprobe deshalb **direkt am Datastore** (`/nodes/pve/storage/pbs/content`).
 - ✅ **Startreihenfolge auf pve repariert** (TP32): HA startet nach MariaDB, Docker, MQTT, z2m25.
 
 ## 🔴 Was den Plan ändert — drei Funde vom 2026-08-25 (spät), alle live erhoben

docs/teilprojekte.md

@@ -1473,7 +1473,10 @@ Grafana **nie gab**. Im FQDN-Smoke-Test lieferte `grafana.emsenhuber.net` trotzd
 oeffentlichen FQDN sagt nichts ueber das Origin, solange Access davor steht. **Ein toter Dienst
 sieht monatelang gesund aus.** ⇒ Caddy-Zeile entfernt (16 Sites), **LXC 104 zerstoert** und aus dem
 Backup-Job genommen. ~~Die 14 PBS-Snapshots bleiben bewusst stehen.~~ **Am 2026-08-25 auf
-User-Entscheid ebenfalls weg** — direkt gegen den Datastore gegengeprueft (`ct/104` = 0), nicht nur
+User-Entscheid ebenfalls weg** — zusammen mit den vier gestoppten Gaesten `103 minarca`,
+`109 node-red`, `115 hms-mqtt-publisher` und `201 openproject` (28 Snapshots). **Damit laeuft auf
+pve jeder existierende Gast**, 11 LXC + 2 VMs, kein `stopped` mehr. ⚠️ **Snapshot-Liste vor dem
+`destroy` einsammeln** — `pvesm list --vmid` meldet danach 0, obwohl die Backups noch liegen** — direkt gegen den Datastore gegengeprueft (`ct/104` = 0), nicht nur
 gegen `pvesm list --vmid`, dessen Filter nach dem `destroy` nicht mehr aussagekraeftig ist. Wiederaufbau spaeter als eigener Punkt, dann nach TP32-Systematik.
 
 #### ✅ Abnahme 2026-08-25 (spaet) — 16 von 16 Sites gegen den Host-Header gemessen