feat: verbesserte Netzwerkfähigkeit und Chat-Test integriert

- **Discovery:** Unterstützung für Multi-Interface-Broadcast und manuelle IP-Eingabe.
- **UI:** Chat-Test für Verbindungsprüfung hinzugefügt.
- **ViewModel:** Datenübertragungslogik (Ping/Pong, Chat) implementiert.
- **Workflow:** Windows-MSI-Build als separaten Job hinzugefügt.

Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>

docs/01_Architecture/adr/0027-netzwerk-discovery-interface-binding.md

@@ -1,20 +1,33 @@
 # ADR-0027: Netzwerk-Discovery & Interface-Binding
 
 ## Status
-In Prüfung (Wartet auf PoC)
+
+Akzeptiert & Implementiert (05.05.2026)
 
 ## Kontext
-Desktop-Rechner auf Turnieren sind oft mit mehreren Netzwerken gleichzeitig verbunden (z.B. LAN für das Turnier-Netzwerk, WLAN für Internet-Hotspot). Automatische Discovery-Dienste (JmDNS) wählen ohne explizite Konfiguration oft das falsche Interface, wodurch sich Clients und Master nicht finden.
+
+Desktop-Rechner auf Turnieren sind oft mit mehreren Netzwerken gleichzeitig verbunden (z.B. LAN für das
+Turnier-Netzwerk, WLAN für Internet-Hotspot). Automatische Discovery-Dienste (mDNS) wählen ohne explizite Konfiguration
+oft ein Interface, das für die anderen Teilnehmer nicht erreichbar ist (Bridging-Probleme zwischen LAN und WLAN). Zudem
+blockieren einige Router Multicast-Pakete zwischen WLAN und LAN-Segmenten.
 
 ## Entscheidung
-Wir führen ein explizites Netzwerk-Management für die Initialisierung ein.
 
-1. **Interface-Selektion:** Der Benutzer muss bei der technischen Initialisierung explizit wählen, über welches Netzwerk-Interface (IP-Adresse/Adapter) die App kommunizieren soll. Die UI zeigt hierfür benutzerfreundliche Namen (WLAN, Ethernet) an.
-2. **Geführte Discovery:** Sobald ein Interface gewählt ist, startet ein "Radar-Modus". Dieser scannt aktiv via JmDNS nach vorhandenen Master-Geräten.
-3. **Adaptive Rolle:** Findet die Discovery einen Master, wird dem Benutzer die Rolle "Client" vorgeschlagen. Die UI bleibt jedoch flexibel für manuelle Rollenwechsel.
-4. **Fokus-Management:** Nach Auswahl der Rolle wird der Fokus automatisch in das erste relevante Eingabefeld (Gerätename) gesetzt, um einen reibungslosen Workflow zu ermöglichen.
+Wir führen ein robustes, mehrstufiges Netzwerk-Management für die Initialisierung ein:
+
+1. **Multi-Interface Broadcast:** Der Master registriert seinen Dienst proaktiv auf **allen** verfügbaren
+   Netzwerk-Interfaces (IPv4). Dies erhöht die Chance massiv, dass Clients in verschiedenen Segmenten (WLAN/LAN) den
+   Master finden.
+2. **Interface-Selektion:** Der Benutzer kann weiterhin ein bevorzugtes Interface wählen. Die Master-Info-Card zeigt die
+   Erreichbarkeit transparent an.
+3. **Manueller IP-Fallback:** Wenn mDNS fehlschlägt, kann die IP des Masters manuell eingegeben werden. Dies ist der "
+   Ultima-Ratio"-Weg für restriktive Netzwerke.
+4. **Konnektivitäts-Check (Chat & Self-Test):** Nach dem Handshake wird ein Modal geöffnet, das einen automatischen
+   Ping-Pong Test durchführt und einen Test-Chat bietet. Dies verifiziert die reale Datenübertragung (Serialisierung,
+   WebSockets) noch vor Abschluss des Setups.
 
 ## Konsequenzen
-- Verhindert "Geistersuchen" im falschen Netzwerk.
-- Erhöht die Benutzerfreundlichkeit durch automatische Vorschläge.
-- Erfordert Zugriff auf System-Netzwerk-APIs in der Desktop-Shell.
+
+- Deutlich höhere Stabilität in heterogenen Netzwerkumgebungen.
+- Transparenteres Feedback für den Anwender bei Verbindungsproblemen.
+- Der Chat dient als "Connectivity-Proof" für das Support-Personal vor Ort.