Die cap-wifiN-Nummern sind nicht stabil -- und die Karte gehoert zum Messlauf

Beim Bauen der Gegen-AP-Automatik fiel auf, dass die feste AP-Tabelle in
server.py und tp25-gehweg-auswertung.py nicht zum Live-Zustand passt: heute
sind cap-wifi1/2 = ap2 und cap-wifi3/4 = ap1. Der Manager vergibt die Nummern
dynamisch beim Anmelden der CAPs; ap1 hat sich beim Rueckbau auf ether15 neu
angemeldet.

Der erste Schluss daraus war voreilig ("die alten Auswertungen sind
falsch beschriftet"). Die Gegenprobe widerlegt ihn: mit der HEUTIGEN Karte
haette Technik OG am 08-21 von ap1 mit -43 dBm versorgt worden sein -- in dem
Raum, in dem ap2 steht. Die alte Tabelle war zu ihrer Zeit also richtig und
ist erst durch das Umstecken falsch geworden.

Konsequenz, und das ist der eigentliche Fix: eine live nachgeschlagene Karte
auf alte Daten anzuwenden ist nicht die Loesung, sondern derselbe Fehler mit
umgekehrtem Vorzeichen. Die Zuordnung gehoert zum Messzeitpunkt.

- tp25-walk-messung.sh friert sie als ap-map.txt im Laufverzeichnis ein.
- tp25-gehweg-auswertung.py nimmt ausschliesslich diese Datei. Fehlt sie
  (alle Laeufe vor heute), bleiben die rohen cap-wifiN stehen, mit lauter
  Warnung -- unbeschriftet ist ehrlicher als falsch beschriftet.

teilprojekte.md: TP25 um den Werkzeug-Fund, den neuen Messaufbau (eine Runde
statt zwei) und den Pausenstand ergaenzt.

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

docs/teilprojekte.md

@@ -1364,6 +1364,41 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 > zurückgebaut haben. Der Sticky-Client-Defekt ist damit **platzierungsunabhängig**.
 > ⇒ **Fund E** (`signal-range`-Boden am Manager) bleibt unverändert die richtige Maßnahme und ist nach
 > dem Rückbau der **oberste offene Punkt** in TP25 — nicht erledigt, nicht gegenstandslos.
+> 🔴🔴 **2026-08-22, Werkzeug-Fund mit Rückwirkung auf ALLE bisherigen Messungen: die
+> `cap-wifiN`-Nummern sind NICHT stabil.** Der Manager vergibt sie dynamisch in der
+> Reihenfolge, in der sich die CAPs anmelden — nach dem ap1-Rückbau auf `ether15` sind heute
+> `cap-wifi1/2` = **ap2** und `cap-wifi3/4` = **ap1**, also genau umgekehrt zu der festen
+> Tabelle, die in `tp6-marker/server.py` und `tp25-gehweg-auswertung.py` stand.
+> ⚠️ **Daraus folgt NICHT, dass die alten Auswertungen falsch sind** — der erste Verdacht in
+> diese Richtung war voreilig. Die Gegenprobe spricht dagegen: wendet man die *heutige* Karte
+> auf die Raumkarte vom 08-21 an, wird **Technik OG von ap1 mit −43 dBm versorgt** — in dem
+> Raum, in dem **ap2 steht**. Die alte Tabelle war zu ihrer Zeit also plausibel richtig und
+> ist erst durch das Umstecken falsch geworden.
+> ⇒ **Die Zuordnung gehört zum Messlauf, nicht zur Auswertungszeit.** `tp25-walk-messung.sh`
+> friert sie jetzt als `ap-map.txt` im Lauf ein; die Auswertung nimmt ausschließlich diese
+> Datei und lässt die Namen sonst roh (`cap-wifiN`) — unbeschriftet ist ehrlicher als falsch
+> beschriftet. **Läufe vor dem 2026-08-22 sind nicht rekonstruierbar**; wer ihre AP-Namen
+> zitiert, muss sie an der Physik prüfen (der AP im Raum liefert dort das stärkste Signal).
+>
+> 🆕 **Messaufbau neu gedacht (Christoph, 2026-08-22) — eine Runde statt zwei.** Das frei
+> roamende iPhone zeigt ohnehin, welchen AP ein normaler Client wählt; interessant ist der
+> **andere**. Das S22 wird deshalb per `access-list` automatisch auf den **Gegen-AP** des
+> iPhones gezwungen (`docs/tp25-pin-s22.sh`, Automatik in der Klick-Konsole auf Port 3031).
+> Pro Standort fallen so **zwei** Messpunkte an. Ein Doppelton meldet „beide angemeldet,
+> verschiedene APs" = weitergehen.
+> 🔴 **Die Falle dabei, live erlebt:** ein vom Pin **abgewiesener** Verbindungsversuch ist in
+> den Ping-Daten **nicht** von einem Funkloch zu unterscheiden, und der Manager protokolliert
+> ihn auf `info`-Ebene **gar nicht** (Beleg: zwischen `disconnected, access-list changed` und
+> dem manuellen Reconnect stehen vier Minuten ohne eine einzige Zeile). Android quittiert die
+> Abweisung mit „Verbindung fehlgeschlagen" und **wählt das Netz ab** — danach misst der Rest
+> des Rundgangs Stille. Die Konsole schlägt deshalb mit Ton, Vibration und Vollbanner Alarm,
+> sobald das gepinnte Gerät nirgends hängt, und schreibt nach 45 s vergeblicher Suche
+> `UNERREICHBAR=apX` — denn „der Gegen-AP trägt hier nicht" **ist das Messergebnis**.
+> ⏸️ **Stand bei Sitzungsende 2026-08-22: Rundgang noch nicht gegangen.** Pin gelöst,
+> Automatik aus, `crs326-core` unverändert (die `access-list` steht unter keiner
+> ComplianceRule, es gibt also nichts zu committen). Erster Messwert nebenbei: am Arbeitsplatz
+> iPhone **ap2 −68**, S22 auf ap1 gezwungen **−77…−78**; ohne Pin geht das S22 sofort auf
+> **ap2/5 GHz −71**.
 > 📋 **Übergabe: [`handoff-tp25-session-20260821.md`](handoff-tp25-session-20260821.md).**
 > ✅ **Transaktion `TEST-ether3-trunk-ap1-sideboard` am 2026-08-22 zurückgerollt und geschlossen**
 > (Scope `bridge-vlan`) — `ether3` ist wieder untagged VLAN40, Compliance zurück auf 92/92.