sites: Inventar und Registry an echte Knoten (pve44–pve61) angepasst; ADR-0001/0002/0006 und PLAN §1.3/1.4/9 ergänzt

Inventar mit pve44–pve61 und den Ada-Rechnern gode-pc-05/06 (M4000 weiter
disabled). Registry-ops auf gpu-pve44/gpu-pve48/infra laut Placement, bei
den Ada-Slots entfallen pve_node und vmid (Worker-Registry v2, Task 6.4).
Tests: neuer test_site_knaster_matches_real_nodes, Konsistenztest auf
gpus-Liste umgestellt. ADR-Nachträge zu D1 (Variante B), D2 (eine GPU-VM
pro Knoten) und D3 (Ada bleibt Windows, vorgeschlagen).

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

docs/adr/0002-storage-zfs-kein-ceph.md

@@ -16,3 +16,10 @@ Die Nodes sind mit **1 GbE** verbunden. Jede physische Maschine hat 2–3 SSDs m
 - Bei einem Node-Ausfall gehen höchstens 15 Min. Daten der Infra-VMs verloren. Postgres sichert sich zusätzlich über WAL-Archivierung bzw. PBS.
 - Modellwechsel verursachen Downloads (10 GB ≈ 90 s über 1 GbE). Das ist akzeptabel.
 - Die Speicherbudgets pro Rolle stehen in PLAN.md, Abschnitt 1.4.
+
+## Nachtrag 2026-10-12: Umsetzung als Variante B (D1)
+- Keine Neuinstallation. Die System-SSD bleibt bei ext4 mit LVM-thin: `local` für System, ISOs und Vorlagen, `local-lvm` für die Platten der Gäste.
+- Die zweite SSD ist der ZFS-Pool `tank` (Einzel-SSD, kein Mirror) auf **pve44, pve48 und pve52**. pve46 und pve61 haben nur eine Platte und bleiben ohne ZFS. Die leere 128-GB-SSD `sdc` in pve48 ist noch nicht verplant.
+- Replikation und HA laufen nur zwischen pve44, pve48 und pve52. `infra` (LXC, vmid 101) liegt auf pve44 in `tank` und wird nach pve52 und pve48 repliziert.
+- Die GPU-VMs liegen auf `local-lvm` des eigenen Knotens. Sie werden nicht repliziert, Modelle lassen sich neu laden.
+- Folgen: Fällt eine System-SSD aus, wird der Knoten neu installiert. Gesichert sind dann nur die replizierten Gäste in `tank` und die PBS-Backups. Variante A (Neuinstallation mit ZFS-Mirror, vor Ort) lässt sich später je Knoten nachholen.