TP7.1 nachgebessert: --ssdpUnicastAddr raus, SSDP-Hinweg repariert

Die macOS-Sonos-App fand ihre Player nicht. Ursache war nicht die Firewall
(MEDIA->MAIN ist offen) und nicht der vermutete Race um den globalen
"last SSDP search source"-Slot, sondern die Flagge --ssdpUnicastAddr selbst:

  multicast-relay.py Z. 630 schreibt die Quelle JEDES SSDP-Pakets an
  239.255.255.250:1900 auf <addr>:1901 um (auch NOTIFY), Z. 691 verwirft
  das Paket dann beim Senden auf eth1, weil 10.40.10.21 nicht im VLAN40-Netz
  liegt. Der Hinweg lief damit nie.

Messung vorher: 0 Pakete via eth1 gegen 308 via eth0 in 20 min, 0x
"Received SSDP Unicast" im gesamten Journal seit 2026-08-18. Nachher:
M-SEARCH quellerhaltend in VLAN40, HTTP/1.1 200 OK von 10.40.40.193/.195
an beiden MacBook-Beinen, Drop-Log in:vlan40 out:vlan10 = 0.

- mcast-relay/multicast-relay.service: reparierte Unit jetzt im Repo
  (ausgerollt auf LXC 108, Backup /root/multicast-relay.service.bak-20260825)
- CLAUDE.md: Gotcha korrigiert, Richtungsbilanz als Erstmessung, Hinweis auf
  die SO_REUSEPORT-Falle auf Port 1900 und das dual-homed MacBook (.183/.82)
- docs/teilprojekte.md: Ist-Stand nachgezogen, TP33 (Fernzugriff) als Stub
- docs/teilprojekte-archiv.md: TP7.1-Aussage "--ssdpUnicastAddr ist noetig"
  widerrufen

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

docs/teilprojekte-archiv.md

@@ -618,8 +618,12 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   erweitert (`routeros/tp7.1-core-ether13-trunk.rsc`). Software: `alsmith/multicast-relay` als
   systemd-Unit `multicast-relay.service`.
   - **`--noMDNS` ist Pflicht:** mDNS reflektiert bereits der Core (TP7). Zweimal zu reflektieren
-    erzeugt Duplikate. **`--ssdpUnicastAddr 10.40.10.21`** ist ebenfalls noetig — die Sonos
-    antworten auf einen M-SEARCH per **Unicast**, und diese Antworten muessen zurueckgereicht werden.
+    erzeugt Duplikate. ~~**`--ssdpUnicastAddr 10.40.10.21`** ist ebenfalls noetig — die Sonos
+    antworten auf einen M-SEARCH per **Unicast**, und diese Antworten muessen zurueckgereicht werden.~~
+    🔴 **WIDERRUFEN 2026-08-25:** die Flagge war der Fehler — sie schreibt in `multicast-relay.py` Z. 630
+    die Quelle jedes SSDP-Pakets um, worauf Z. 691 die M-SEARCH beim Senden auf `eth1` **selbst verwirft**
+    (`10.40.10.21` ist nicht im VLAN40-Netz). Der Hinweg lief damit **nie**; ausgebaut, Rückweg wird
+    geroutet (`TP5: MEDIA->MAIN`). Stand + Merkregeln: Ist-Stand in `teilprojekte.md` und Gotcha in `CLAUDE.md`.
 - 🔑 **Warum zwei Beine zwingend sind** (Christophs Frage „vlan40 sollte keinen relay benoetigen?!?"):
   SSDP ist **link-lokales Multicast mit TTL 1**. Der M-SEARCH des MacBooks verlaesst VLAN10 nie, die
   `ssdp:alive`-NOTIFYs der Sonos verlassen VLAN40 nie. Ein Relay kann nur kopieren, was es selbst