TP10 reopened: Mesh-Quell-NAT dokumentiert, widerlegte Handoff-Diagnose entfernt

Der Fix aus 1fddf5d ist live und verifiziert. Dieser Commit traegt die Doku nach und
raeumt eine falsche Diagnose weg, die eine Folge-Session in die Irre gefuehrt haette.

- TP10 (#49) reopened (status:wip), Prosa-Volltext zurueck aus dem Archiv nach
  teilprojekte.md; im Archiv bleibt der Zeiger.
- Neuer Befund dokumentiert: WARP-Clients kommen via cf-mesh mit 100.96.0.0/12 an,
  ausserhalb der Spoke-AllowedIPs (10.40.0.0/16) -> FritzBox verwirft. Beweis-Tabelle
  und Abnahme-Werte im Abschnitt.
- Close-Bedingung ins Issue geschrieben: DDNS-Updater bf4.emsenhuber.net + taeglicher
  GC-Lauf konform. Der Mesh-NAT-Teil ist erledigt.
- docs/handoff-20260928-core-wghub-ping-fix.md GELOESCHT: er behauptete, die fehlende
  Interface-IP von wg-hub sei ein Defekt, und schlug preferred-source vor. Beides
  widerlegt — die fehlende IF-IP ist beabsichtigt (im Archiv dokumentiert), und der
  Core-eigene Ping ist kein Betriebsproblem. Die Erkenntnis steht jetzt in TP10.

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

docs/teilprojekte-archiv.md

@@ -692,6 +692,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 <a id="tp10"></a>
 
 ### TP10  ·  Gitea #49 — Multi-Site VPN — beide WG live auf ap1-Hub (`docs/tp10-vpn-migration.md`)
+> ♻️ **REOPENED 2026-10-03 → Volltext zurück in [`teilprojekte.md`](teilprojekte.md#tp10)** (neuer Befund: Mesh-Quell-NAT `100.96.0.0/12` → `10.40.10.1`). Dies ist die eingefrorene Historie.
 > **Details/Cutover/Gotchas/Eckdaten → `docs/tp10-vpn-migration.md` (Single Source of Truth).** Research: `docs/research/vpn-comparison.md`.
 - **✅ KERN DURCH (2026-06-27) + EDGE-CUTOVER (2026-07-01):** beide AVM-Tunnel → **2× WireGuard mit Hub auf ap1** migriert. Live: `peer fm`
   (`10.101.0.0/24`, bidirektional, myfritz-Endpoint) **und** `peer dw` (`10.95.10.0/24`, CGNAT-Dial-in) mit frischem