drift-korrektur: Auth-Sanierung (Bearer) gehört in TP16.3, nicht als Vorab-Notiz

TP16.3 existiert seit 2026-08-17 (Quick-Index Z. 194, Body Z. 401,
Runbook tp16.3-nautobot-mesh-only-runbook.md) und deckt 'alle Tools
über Caddy oder CF + Caddy (extern)' + Auth-Sanierung bereits ab.

Mein Fehler: ich habe im Index nicht nachgeschaut und einen Vorab-Punkt
formuliert, der TP16.3 doppelt. Anwender hat das in dieser Session
explizit markiert ('das darf dir kein 2. mal passieren').

Fix:
- Session-Anker: Vorab-Notiz entfernt, ersetzt durch Verweis auf TP16.3.
- TP16.3-Body: technische Notiz 'n8n-mcp Accept-Header-Strike +
  Auth-Sanierung' eingepflegt (SSE-Header-Konsequenz für künftiges
  Caddy-Fronting, Reihenfolge TP16.3 → TP35 Schicht 2).

Lehre: vor jeder Aussage 'gibt's noch nicht' oder 'neuer TP nötig':
erst grep auf den Quick-Index in teilprojekte.md.

docs/teilprojekte.md

@@ -487,6 +487,23 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
   liefert das Entscheidungskriterium). ⚠️ **Berührt TP5:** der Mesh-Verkehr braucht bei deny-by-default eine
   explizite `forward`-Zeile — s. TP5 Etappe 2.
 
+#### 🆕 Notiz 2026-08-28 — n8n-mcp Accept-Header-Strike + Auth-Sanierung
+- **Live-Befund (opencode-Probing)**: `n8n-mcp` antwortet auf POST mit nur `Accept: application/json` mit
+  `HTTP 406 Not Acceptable: Client must accept both application/json and text/event-stream`. Mit korrektem
+  Accept-Header (= StreamableHTTP-Modus) antwortet derselbe Server `HTTP 200` mit
+  `serverInfo: n8n-documentation-mcp 2.57.1`. ⇒ opencode's `mcp list` zeigt `failed` zu Unrecht — Sidebar
+  bleibt Wahrheit. Volle Diagnose im Session-Anker
+  [`docs/session-20260828-decisions.md`](session-20260828-decisions.md), Abschnitt
+  „MCP-Status-Check (Cold-Start-Race + Accept-Header-Strike)".
+- **Konsequenz für TP16.3**: ein künftiges Caddy-Fronting für n8n-mcp **muss** den SSE-Header durchreichen
+  (`proxy_pass` mit angepasstem `Accept`-Default `application/json, text/event-stream`, oder
+  Caddy mit `header_up`). Sonst antwortet das Backend weiter 406, und die Symptomatik bleibt
+  unsichtbar — der Tunnel steht, aber der Probe schlägt fehl.
+- **Auth-Sanierung**: Anwender-Direktive 2026-08-28 „alle Tools laufen über Caddy oder CF + Caddy
+  (extern), Bearer-Authentifizierung einmal sauber". Gehört thematisch in TP16.3, **nicht** als neuer
+  TP — siehe Quick-Index Zeile TP16.3. Bezug zu **TP35** Schicht 2: Reihenfolge ist TP16.3 → TP35.
+  TP35 wartet mit Schicht 2, bis das Fronting steht.
+
 ### TP17.1 — Shelly Gen4 raus aus dem WLAN ▸ ❌ **VERWORFEN (2026-08-23) — Weg bewiesen, Ziel damit nicht erreichbar** — 📋 `docs/tp17.1-shelly-gen4-funkmigration-runbook.md`
 > ❌ **User-Entscheid 2026-08-23 nach dem Pilot: stoppen und zurückbauen.** Auslöser war Christophs
 > strukturelle Frage: *„zigbee sollte die antwort auf die vielen radios auf -iot geben. nutzt aber