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/tp25-gehweg-auswertung.py

@@ -15,6 +15,7 @@ import argparse
 import csv
 import os
 import re
+import sys
 import urllib.parse
 
 
@@ -23,8 +24,38 @@ def sec(t):
     return h * 3600 + m * 60 + s
 
 
-AP = {"cap-wifi1": "ap1/5GHz", "cap-wifi2": "ap1/2,4GHz",
-      "cap-wifi3": "ap2/5GHz", "cap-wifi4": "ap2/2,4GHz"}
+# 🔴🔴 Hier stand bis 2026-08-22 eine feste Tabelle -- mit VERTAUSCHTEN APs: cap-wifi1/2
+#     sind ap2, nicht ap1 (live belegt ueber cap=, configuration= und Kanal). Die Baender
+#     stimmten, die Identitaet nicht. Der Manager vergibt die cap-wifiN-Nummern DYNAMISCH in
+#     der Reihenfolge, in der sich die CAPs anmelden -- eine Konstante dazu ist nur bis zum
+#     naechsten AP-Reboot richtig und faellt danach still falsch aus.
+#
+#     ⚠️ OFFEN: ob die Messungen vom 2026-08-21 (Raumkarte, Sideboard-Test) mit vertauschten
+#     AP-Namen ausgewertet wurden, ist NICHT geprueft. Die Rohdaten sind unberuehrt -- es geht
+#     allein um die Beschriftung. Betroffen waere u.a. Fund F ("Schlafzimmer -61 ap1 -> -83
+#     ap2") und damit die Sideboard-Entscheidung. Vor dem Zitieren alter Zahlen klaeren.
+def ap_karte(run_dir):
+    """cap-wifiN -> apX/Band, aus der Karte DIESES Messlaufs (ap-map.txt).
+
+    🔴 Ausdruecklich NICHT live nachschlagen. Die Nummern gelten nur fuer den Zeitpunkt der
+       Messung; ein spaeter erzeugtes Mapping auf alte Daten anzuwenden ergibt eine
+       selbstbewusst falsche Antwort. Fehlt die Datei (alle Laeufe vor 2026-08-22), bleiben
+       die rohen cap-wifiN stehen -- unbeschriftet ist ehrlicher als falsch beschriftet.
+    """
+    pfad = os.path.join(run_dir, "ap-map.txt")
+    if os.path.exists(pfad):
+        with open(pfad) as fh:
+            return dict(z.strip().split("=", 1) for z in fh if "=" in z)
+    print("⚠️  Kein ap-map.txt in diesem Lauf -- AP-Namen bleiben roh (cap-wifiN).\n"
+          "    Fuer Laeufe vor 2026-08-22 ist die Zuordnung NICHT rekonstruierbar: sie haengt\n"
+          "    daran, in welcher Reihenfolge sich die CAPs damals angemeldet haben.\n"
+          "    Anhaltspunkt aus der Physik: der AP im Raum sollte dort das staerkste Signal\n"
+          "    liefern (ap2 steht in Technik OG, ap1 haengt an core ether15).",
+          file=sys.stderr)
+    return {}
+
+
+AP = {}
 
 
 def ros_ms(v):
@@ -40,6 +71,9 @@ def main():
     ap.add_argument("--dir", required=True)
     a = ap.parse_args()
 
+    global AP
+    AP = ap_karte(a.dir)
+
     pings = []
     csv_path = os.path.join(a.dir, "walk-ping.csv")
     if os.path.exists(csv_path):