chore(docs+infra): update roadmap, improve home server plan, and archive outdated reports

- Adjusted infrastructure roadmap to use VM instead of nested LXC for Docker hosting, enhancing isolation and compatibility.
- Clarified multi-architecture CI/CD setup with native ARM64 builds and QEMU-based x86_64 builds.
- Updated documentation to include backup and offline-first strategies.
- Archived outdated session logs and reports for better file organization.

docs/99_Journal/2026-02-06_Infrastructure_Planning.md

@@ -4,37 +4,47 @@
 **Teilnehmer:** User (Owner), Lead Architect, DevOps Engineer
 
 ## 1. Zusammenfassung
-In dieser Session wurde die zukünftige Infrastruktur für den Home-Server (Minisforum MS-R1) geplant und eine Anforderung für das Reporting-System (PDF-Generierung) aufgenommen.
+In dieser Session wurde die zukünftige Infrastruktur für den Home-Server (Minisforum MS-R1) detailliert geplant und korrigiert. Zudem wurden Anforderungen für Reporting und Offline-Fähigkeit präzisiert.
 
 ## 2. Reporting / Printing (Vorgemerkt)
 Der User benötigt eine Lösung zum Generieren von personalisierten PDFs (Startlisten, Ergebnislisten, Protokolle).
 *   **Status:** Als "Next Step" in die Roadmap aufgenommen.
-*   **Offene Fragen:** Architektur (Zentral vs. Dezentral), Technologie-Stack.
+*   **Architektur:** Dezentraler Microservice (um Resource-Bursts vom Core-System fernzuhalten).
 *   **Aktion:** Wurde in `MASTER_ROADMAP_2026_Q1.md` dokumentiert.
 
 ## 3. Infrastructure Setup (Minisforum MS-R1)
-Der User hat neue Hardware bestellt (ARM64 Architektur).
-
 **Hardware Specs:**
+*   Model: Minisforum MS-R1
 *   CPU: 12 Kerne ARM (CP8180)
 *   RAM: bis 64GB LPDDR5
 *   Network: 2x 10G LAN
+*   Storage: NVMe + USB-SSD (Backup)
 
-**Entscheidung: "The Incus Way"**
-Da Proxmox auf ARM experimentell ist, wurde folgender Stack beschlossen:
-1.  **Base OS:** Debian 12 (Bookworm).
+**Software Stack (Final Decision):**
+1.  **Base OS:** Debian 12 (Vendor Variant, vorinstalliert/angepasst für Treiber).
 2.  **Hypervisor:** **Incus** (Community Fork von LXD).
-3.  **Container-Strategie:**
-    *   `infra-gitea` (LXC): Gitea + Actions Runner (Native ARM Builds).
-    *   `docker-host-prod` (LXC mit nesting): Docker Host für den Meldestelle-Stack.
-4.  **Networking:** Cloudflare Tunnel.
+3.  **Virtualization Strategy:**
+    *   `infra-gitea` (LXC Container): Gitea + Actions Runner.
+        *   *Vorteil:* Leichtgewichtig, Native ARM Builds via Runner.
+    *   `docker-host-prod` (**VM**): Debian VM als Docker Host.
+        *   *Grund:* Bessere Isolation, Kernel-Unabhängigkeit vom Host, keine "Nesting"-Probleme (OverlayFS/ZFS).
+4.  **CI/CD & Build Strategy:**
+    *   **Tool:** `docker buildx` auf dem Gitea Runner.
+    *   **ARM64 Images:** Werden **nativ** gebaut (rasend schnell, da Host = ARM).
+    *   **x86_64 Images:** Werden via **QEMU-Emulation** gebaut (langsamer, aber funktional).
 
-**Vorteile:**
-*   Native Performance auf ARM.
-*   Snapshots & Backups (via ZFS/Btrfs).
-*   Saubere Trennung von Infrastruktur (Gitea) und Applikation (Docker).
+## 4. Networking & Offline-First
+*   **Remote Access:** Cloudflare Tunnel.
+*   **Local LAN (Offline):**
+    *   Die "Main-Native-Desktop-App" (Meldestelle) fungiert als lokaler Anchor/Server im LAN.
+    *   Clients (Zeitnehmer) verbinden sich via LAN.
+    *   **Discovery:** Lokale DNS-Strategie oder Service Discovery (mDNS) notwendig, damit Clients den Server auch ohne Internet finden.
 
-## 4. Nächste Schritte
+## 5. Backup
+*   **Strategie:** Automatisierte Snapshots/Backups auf externe **USB-SSD**.
+*   **Motto:** "Kein Backup, kein Mitleid."
+
+## 6. Nächste Schritte
 *   Warten auf Hardware-Lieferung.
-*   Installation & Setup gemäß Plan.
-*   Einrichtung der CI/CD Pipeline (Gitea Actions) für ARM-Builds.
+*   Installation & Setup gemäß korrigiertem Plan (VM statt LXC für Docker).
+*   Vorbereitung der CI/CD Pipelines auf Multi-Architektur (Buildx/QEMU).