TP16.1 Scharfschalten: Plan-Probe gescheitert (Token-Scope) — Blocker vollstaendig vermessen

POST /warp_connector -> 10000/403, identisch zu 2026-07-17. Neu: Gegenproben
zeigen, dass auch 4.1 blockiert ist (devices/settings GET 403) — es fehlen ZWEI
Permissions, nicht eine. MCP-Read-Gegenprobe belegt: Account kann es, Token darf
nicht -> Free-Plan-Frage bleibt offen. Am Geraet wurde nichts angefasst.

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

docs/teilprojekte.md

@@ -478,7 +478,10 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - Abh.: TP14.1/14.2 ✅. Verwandt: **TP11** (CF-Tunnel-Track-B/C + Access), #1033. SSoT: `docs/cf-tunnel-mapping.md`. Memory `project_cf_tunnel_1033`.
 - ✅ **Incident 2026-07-16 (User unterwegs, WARP „spinnt", keine BF-IPs mehr) ▸ Public-FQDN-Teil gefixt:** macmini-Connectoren (`cloudflared-bfnas`/`-bfpve`) flappten live unter QUIC/UDP (Docker-Desktop-Bridge-NAT) → `bf-nas`/`bf-pve` von 2 auf 1 Connector degradiert (HA faktisch weg, nicht down). Fix: beide auf `TUNNEL_TRANSPORT_PROTOCOL=http2` umgestellt (rollend, 0 Downtime), wieder voll HA. Konvention: macmini-Connectoren künftig immer `http2`. **ICMP-Befund (getrennt, strukturell):** TCP über die WARP-Route ging überall, ICMP nicht (fm 36 %/bf 100 %/dw 100 % Loss) — cloudflared ist QUIC-Proxy, kein WireGuard. **Kurz als „bf-pve-Route wegen USV" notiert (Commit `1c1a676`) → REVIDIERT** (Begründung invertiert: bf-pve-Connectoren laufen auf NAS+macmini, nicht pve). Details: `docs/cf-tunnel-mapping.md §13`. **→ Richtungswechsel für Private Access = TP16.1.**
 
-### TP16.1 — Private Access via native Cloudflare Mesh (WireGuard) auf `crs326-core` ▸ 🟢 **GATE OFFEN, ausführungsreif (2026-08-16)** — Scharfschalten = eigene Session — `docs/tp16.1-warp-mesh-native-crs326.md`
+### TP16.1 — Private Access via native Cloudflare Mesh (WireGuard) auf `crs326-core` ▸ 🔴 **BLOCKIERT auf §4.0 (Token-Scope), user-gated (2026-08-16)** — `docs/tp16.1-warp-mesh-native-crs326.md`
+- 🔴 **Scharfschalt-Versuch 2026-08-16 — Plan-Probe ausgeführt, reproduzierbar gescheitert.** `POST /warp_connector` → `10000`/HTTP 403, identisch zum 2026-07-17. **Am Gerät wurde nichts angefasst** (kein `/system backup`, kein `cf-mesh`-Interface, keine Route) — der Blocker sitzt vor dem ersten Geräte-Eingriff, Ausnahme #4 wurde also gar nicht erst gezogen.
+- 🆕 **Die Probe hat den Blocker vollständig vermessen — es fehlen ZWEI Permissions, nicht eine.** Bisher stand nur §4.0 im Runbook; die Gegenproben zeigen, dass `devices/settings` für den Token schon **lesend** `403` ist → **auch §4.1 (Unique Device IP, Device-Profil, Split-Tunnel) wäre gescheitert**. Ohne diesen Fund hätte die Session den Token zweimal nachziehen müssen. **In EINEM Dashboard-Edit ergänzen:** „Cloudflare One Connector: WARP" → Edit · „Zero Trust" → Edit · „Cloudflare One Networks" → Edit. Klickpfad + Beleg-Tabelle in `docs/tp16.1-…md` §4.0.
+- 🧭 **Free-Plan-Frage weiterhin OFFEN, nicht beantwortet.** Dass der `cloudflare`-MCP (OAuth, read-only) dieselben Endpoints sauber liest, beweist nur: der **Account** kann es, der **Token** darf nicht. Ob der Free-ZT-Plan das `POST` erlaubt, zeigt erst der Retry — ein dann *immer noch* scheiternder POST wäre das echte Plan-Gate und löst den LXC-Fallback aus.
 - ✅ **Gate erfüllt (2026-08-16):** die Bedingung „gated bis TP21 den CRS326 abdeckt" ist eingelöst — `crs326-core` ist seit 2026-08-08 der produktive L3-Router und seit 2026-08-13 in Nautobot adoptiert (68/68 compliant). Runbook §3 neu gemessen, §4.3 von Platzhalter auf **echte Werte** gezogen.
 - 🧭 **Erwartung geraderücken (wichtig, weil leicht zu verwechseln): das Mesh ersetzt die CF-Tunnel NICHT.** TP16.1 löst ausschließlich den **privaten** Zugang (unterwegs → `10.40.0.0/16` per IP, **inklusive ICMP**) und tauscht dort den cloudflared-QUIC-Proxy gegen natives WireGuard auf dem Core. Die **öffentlichen FQDNs bleiben** auf dem 3-Tunnel-HA aus TP16. Beide Stränge laufen nebeneinander — die HA-Degradierung aus TP16 (2026-08-16) wird davon **nicht** geheilt und bleibt ein eigener offener Punkt.
 - 📌 **Live-Befunde 2026-08-16 (read-only erhoben, kein Eingriff):**