ct/104-Snapshots weg; Doku nachgezogen

User-Entscheid: auch die Grafana-Backups loeschen. Gegenprobe direkt am
Datastore (ct/104 = 0), nicht ueber 'pvesm list --vmid' -- dessen Filter
ist nach dem destroy nicht mehr aussagekraeftig.

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

docs/teilprojekte.md

@@ -1472,8 +1472,9 @@ Grafana **nie gab**. Im FQDN-Smoke-Test lieferte `grafana.emsenhuber.net` trotzd
 ⚠️ **Das ist exakt die Falle aus TP16.3 §8, diesmal in freier Wildbahn:** ein Statuscode vom
 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**, sie sind die einzige Kopie
-etwaiger Dashboards. Wiederaufbau spaeter als eigener Punkt, dann nach TP32-Systematik.
+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
+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
 Dienst `active`+`enabled`, Probe von einem **zweiten Host** (pve, VLAN20) mit