TP10 Doku konsolidiert: kanonischer Runbook + kompakter Kontext-Digest

- tp10-vpn-migration.md zur Single Source of Truth umgeschrieben: widerspruechliche
  alte Transfernetz-Tabelle/MyFRITZ-Endpoint entfernt, aktueller Stand (Proxy-ARP
  LAN-IP, DDNS bf4.emsenhuber.net, dual-range DW, geparkter ap1-Hub, vertagt+
  gebuendelt mit Bridge-Cutover, v6-Variante) konsolidiert.
- teilprojekte.md TP10-Eintrag von verbose Saga auf kompakten Status + Verweis gekuerzt.
- tp10-context-digest.md neu: ultrakompakter Handoff (lokal via Ollama nemotron-3-nano:4b
  destilliert, fakten-gegengeprueft) fuer kleines Kontextfenster.

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

docs/teilprojekte.md

@@ -137,37 +137,17 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
 - Abh.: TP4. (Research erledigt, s. TP-R + Config-Skizze im Report.)
 
 ### TP10 — Multi-Site VPN ▸ 🅿️ VERTAGT — gebündelt mit Bridge-Cutover (`docs/tp10-vpn-migration.md`)
-- **🅿️ ENTSCHEIDUNG 2026-06-17:** TP10 **vertagt** und **mit dem permanenten FB-Bridge-Cutover gebündelt** (statt
-  Parallelbetrieb vorher). Begründung: VPN-auf-FB und FB-Bridge schließen sich aus (Bridge = Modem = keine VPN-
-  Terminierung) → die Migration MUSS am Bridge-Tag passieren, nicht davor. Macht man beides in einem Cutover, hat ap1
-  dann die echte Public-IP → **kein FB-Port-Forward-Umweg nötig** (Spokes zeigen direkt auf ap1/DDNS). **FM-PoC ✅**
-  hat den WG-Spoke-Fix bewiesen → Migration de-risked. **Park-Zustand ap1:** Peers `disabled`, WG-Routen entfernt
-  (FM/DW laufen wieder über die FB), `wg-hub` bleibt (Key erhalten), Firewall-Regeln bleiben (TP5-Vorarbeit).
-  Beide VPN **vorerst über die FB** (`10.40.41.254`): FM = IPsec, DW = FB-WG.
-- **✅ Phase A (2026-06-16):** ap1-WG-**Hub** `wg-hub` live (UDP **51821**, MTU 1412, keine IF-IP). 2 Peers
-  vorkonfiguriert: **FM** `10.101.0.0/24` (war IPsec) = `peer1` · **DW/Geli** `192.168.178.0/24` CGNAT (war WG) = `peer2`.
-  Routen + Firewall (input/forward) gesetzt; NAT braucht nichts (Egress wg-hub ≠ masq-Interface). Hub-Pub
-  `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=`, Endpoint `xvbeo64jqlqd9gfo.myfritz.net:51821`.
-  Spoke-Configs in `routeros/.secrets/wg-{fm,dw}.conf` (Private-Keys, nicht im Git). FB-Portfreigabe 51821→ap1 gesetzt.
-- **⛔→💡 Phase-B-Versuch FM gescheitert, ROOT CAUSE gefunden (2026-06-16):** `.conf` importiert, IPsec voreilig
-  aus → FM weg, revertiert. **Echt-Host-Test (WG reaktiviert):** Ping realer Host `10.101.0.10` → Antwort aus
-  `10.255.255.2` → **FB-NAT bestätigt.** **Ursache:** unsere `.conf` nutzte eine **Transfernetz-Adresse**
-  (`10.255.255.2/32`) → FRITZ!OS behandelt das als Einzelgerät → masqueradet. **AVM nutzt Proxy-ARP, KEIN
-  Transfernetz** → FB-WG-Interface-`Address` muss die **FB-LAN-IP** sein (FM `10.101.0.254/24`, DW `192.168.178.1/24`),
-  Transfernetz streichen, AllowedIPs `10.40.0.0/16`. **→ Ansatz machbar.** Configs `routeros/.secrets/wg-{fm,dw}.conf`
-  korrigiert. FM aktuell auf **IPsec** (Sicherheitsnetz); ap1-WG-Hub bleibt (inert).
-- **⏳ Resume = Bridge-Tag (ein Cutover):** Liwest-Anruf → FB wird Modem, ap1 = Edge mit Public-IP. Dann WG-Hub auf
-  ap1-Endpoint (DDNS) aktivieren, Spokes neu anlegen via Klickanleitung `routeros/fritzbox-wg-lanlan-klickanleitung.md`
-  (**FB-LAN-IP als Interface-Adresse!**), Echt-Host-Test gegen `10.101.0.10`. **DW:** kein Parallelbetrieb möglich
-  (Geli-FB lehnt 2 WG zum selben Zielnetz ab) → direkter Swap via temporärem Admin-Tunnel (anderes Zielnetz, da
-  CGNAT-Fernzugang/MyFRITZ fehlt). Spoke-Keys/-Configs bleiben in `routeros/.secrets/wg-{fm,dw}.conf`.
-- **Empfehlung:** **Hybrid** — **WireGuard Site-to-Site-Backbone** (BF/hAP = WG-**Hub**, FM/DW = FritzBox-**Spokes**, hub&spoke, **KEINE Zusatz-HW**) **+ WARP für Remote-User** (ergänzt, ersetzt nicht).
-- **WARP kann FBs NICHT direkt** ansprechen → bräuchte Connector-Host hinter der FB (an reinen-FB-Standorten FM/DW unattraktiv).
-- **Vorab-Check (User, entscheidend):** WAN je Standort — **public/dynamisch (OK: DynDNS/MyFRITZ) vs. CGNAT/DS-Lite am BF-Hub (= K.O. → dann CF/WARP-Pfad, CGNAT-immun)**.
-- WG-Gotchas: keine IP aufs WG-IF (MikroTik), AllowedIPs=Tunnel+LAN-CIDRs, MTU 1412, Keepalive 25. ap1 hat noch KEIN WG (Neuaufbau).
-- **IST-Zustand (User 2026-06-16):** Die BF-FritzBox terminiert AKTUELL **2 produktive Site-to-Site-Tunnel** (AVM LAN-LAN: **1× IPsec + 1× WireGuard**). Migrationsziel: **2× WireGuard** mit Hub auf ap1, FB-Standorte als Spokes.
-- ⚠️ **TP10 ist Voraussetzung für den permanenten FB-Bridge-Mode (AP4.1/TP4).** Solange die FB die 2 Tunnel terminiert, muss sie Router bleiben → FB-Bridge nur reversibel testbar, nicht dauerhaft.
-- Abh.: WAN-Check; Hub sinnvoll nach TP4 (Router-Cutover). **Blockiert:** permanenten FB-Bridge-Mode.
+> **Details/Cutover/Gotchas/Eckdaten → `docs/tp10-vpn-migration.md` (Single Source of Truth).** Research: `docs/research/vpn-comparison.md`.
+- **🅿️ VERTAGT, gebündelt mit Bridge-Cutover (2026-06-17):** VPN-auf-FB ⊕ FB-Bridge schließen sich aus → Migration am
+  Bridge-Tag (dann ap1 = Edge mit Public-IP, **kein Port-Forward-Umweg**). Beide VPN vorerst über die FB: **FM=IPsec, DW=FB-WG**.
+- **💡 Root Cause (FM-PoC bewiesen):** FB masqueradet WG, wenn die Interface-`Address` eine **Transfernetz-IP** ist →
+  muss die **FB-LAN-IP** sein (AVM Proxy-ARP). Damit ist der WG-Spoke-Ansatz machbar.
+- **Stand:** Hub `wg-hub` (UDP 51821, Key `P/bzt…`, MTU 1412) auf ap1 **geparkt** (Peers disabled, Routen entfernt,
+  Firewall = TP5-Vorarbeit bleibt). Endpoint = DDNS **`bf4.emsenhuber.net:51821`** (Cloudflare, DNS-only → 86.56.201.104).
+  **DW-Config bei Geli vor Ort gestaged** (2026-06-17; dual-range `192.168.178.0/24` + künftig `10.95.10.0/24`).
+  v6-direkt-Variante (Gelis natives v6) als spätere Option vermerkt.
+- **Offen:** ap1-Seite aktivieren (peer2 + Routen für beide DW-Ranges), sobald BF erreichbar.
+- ⚠️ **Blockiert** den permanenten FB-Bridge-Mode (AP4.1/TP4) bis zur Migration.
 
 ### TP11 — Monitoring & Mgmt-Control-Plane ▸ research-gated
 - MikroMCP + omada-mcp + **SNMP/icinga-mikrotik**, RoMON, NTP, **E-Mail-Alerts**, Netwatch. → Teil von `docs/research/routeros-capabilities.md`.