TP3-Rebuild: ap1+ap2 als reine Standalone-APs (CAPsMAN weg)

Beide hAP ax² neu als Standalone-Access-Points provisioniert, kein CAPsMAN mehr:
- ap1 10.40.99.11 (core ether15), ap2 10.40.99.12 (branch ether24)
- Uplink geraeteseitig auf ether1 (PoE-Port, poe-out=off); ether2 aus Trunk entfernt
- 6 SSIDs (main WPA3+FT; infra/iot/media/untrusted/guest WPA2+3), iot nur 2,4 GHz,
  media FT=no; jede SSID mit eigenem datapath bridge+vlan-id -> TP3.1-Leck strukturell weg
- Kanaele non-DFS: ap1 ch36/ch1, ap2 ch149/ch11
- Einheitliches Admin-PW auf allen 4 MikroTik (core/branch/ap1/ap2)

Nautobot As-built (nautobot/ingest-ap-rebuild.py): ap1/ap2 Rolle Wireless AP + Active,
Mgmt .99.11/.99.12, ether1-Trunk, stale L3-Objekte (vlan10-90/100, wg-hub) entfernt;
crs326-core primary_ip4 auf .99.1 korrigiert. Verifiziert per GraphQL.

Doku: CLAUDE.md Hardware-Tabelle + teilprojekte.md TP3 aktualisiert.
Configs/PSKs liegen gitignored unter routeros/.secrets/.

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

docs/teilprojekte.md

@@ -107,6 +107,7 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
   - **Begründung (kein Widerspruch zu Nautobot, aber ein echter Reibungspunkt):** CAPsMAN erzeugt auf dem CAP **dynamische** Objekte (`wifi13–22`), die nie in dessen eigener Config stehen → Golden-Config-Compliance sieht auf ap2 faktisch nichts. Genau diese Halbheit war die Ursache von TP3.1 (CAPsMAN schrieb `datapath.vlan-id` nicht auf die Leitung und legte die tagged-Member am CAP nicht an).
   - **Was NICHT verloren geht:** 802.11r/k/v braucht kein CAPsMAN, sondern nur gleiche SSID/PSK/Mobility-Domain → Fast-Roaming bleibt. Preis: Radio-/Kanaländerungen sind zwei Deployments statt eines Provision-Pushes — mit Nautobot ohnehin ein Job-Run.
   - **Reihenfolge:** WLAN-Neuprovisionierung erst **nach** dem CRS326-Bring-up (TP15), da Routing/DHCP/DNS vorher umziehen.
+  - ✅ **DURCH (2026-08-08): beide APs als reine Standalone-APs neu provisioniert, CAPsMAN weg.** ap1 `10.40.99.11` (an core `ether15`), ap2 `10.40.99.12` (an branch `ether24`); Uplink geräteseitig auf **`ether1`** (PoE-Port, `poe-out=off`) umgestellt, ether2 aus dem Trunk entfernt. 6 SSIDs (main WPA3+FT / infra/iot/media/untrusted/guest WPA2+3, iot nur 2,4 GHz, media FT=no); **jede SSID mit eigenem `datapath` bridge+vlan-id** → das TP3.1-„cfg-main-2g ohne datapath"-Leck ist strukturell weg. Kanäle non-DFS ap1 ch36/ch1, ap2 ch149/ch11. Client-Test grün (VLAN10/30-Leases korrekt). Configs `routeros/.secrets/ap{1,2}-prov-base.rsc`, PSKs `routeros/.secrets/wlan-psks.env`, As-built → Nautobot via `nautobot/ingest-ap-rebuild.py`. **Einheitliches Admin-PW auf allen 4 MikroTik** (User-Vorgabe). Henne-Ei beim Bring-up: Werks-`192.168.88.1` über Core-Temp-Pfad (`192.168.88.2` + masq, wieder entfernt) via scp+`/import`; Werks-Inline-Overrides auf wifi1/wifi2 mussten geleert werden (`!configuration.ssid !security.*`), sonst funkt die Main-VAP die Werks-SSID. Offen: DoH auf core (nur plain 1.1.1.1), breiterer CLAUDE.md-Gotcha-Cleanup (ap1-als-L3-Router-Referenzen sind überholt).
 
 ### TP3.1 — ap2 VLAN-Trunk-Fix ▸ ✅ Config live (2026-07-01) — `routeros/tp3.1-ap2-vlan.rsc`
 - **Root Cause:** ap2 (CAP, local forwarding) hatte `bridge vlan-filtering=no` → `datapath.vlan-id` wurde nie