fix(telefon): FreeSWITCH mit -nonat starten, damit der launchd-Watchdog es hochbekommt

Unter launchd blockiert macOS' Local-Network-Privacy das Senden ins LAN
(send() liefert EPIPE, UserEventAgent: "Got local network blocked
notification"). FreeSWITCH schickt in switch_core_init eine NAT-PMP-Anfrage
an den Router (192.168.2.1:5351), bevor es SIGPIPE ignoriert, und stirbt
daran ~0,5 s nach dem Backgrounding (mit -nf: exit 141). Aus der Shell
greift die Sperre nicht, deshalb lief der manuelle Start.

Reproduziert mit einer Testinstanz (eigene Ports, ohne Gateways) unter
einem temporaeren LaunchAgent: ohne -nonat stirbt sie nach ~2 s, mit
-nonat laeuft sie (status UP, Ext-RTP-IP per STUN wie live). Die
NAT-Erkennung fand live ohnehin nichts (nat_map status: UNKNOWN).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011csZF3rmXJSAtukDxUMFgy

telefon/starten.sh

@@ -79,7 +79,14 @@ else
   # -rp: Echtzeit-Priorität. Auf einem Rechner, der nebenher Whisper und ein
   # Sprachmodell laufen lässt, kommt FreeSWITCH sonst nicht rechtzeitig dran und
   # das Audio stückelt - RTP will alle 20 ms ein Paket losschicken.
-  freeswitch -nc -rp -nonatmap \
+  # -nonat: keine NAT-PMP/UPnP-Erkennung am Router (192.168.2.1:5351). Unter
+  # launchd (Watchdog) blockiert macOS' "Lokales Netzwerk"-Datenschutz jedes
+  # Senden ins LAN mit EPIPE; so frueh im Start ignoriert FreeSWITCH SIGPIPE
+  # noch nicht und stirbt 0,5 s nach dem Backgrounding - ohne Log, ohne
+  # Crash-Report. Aus einer Terminal-Shell passiert das nicht, deshalb lief es
+  # manuell. Der Router antwortet ohnehin nicht (nat_map status: UNKNOWN); die
+  # externe IP kommt per STUN (vars.xml), Trunks und Sockets brauchen kein LAN.
+  freeswitch -nc -rp -nonat -nonatmap \
     -conf "$FS_ETC" \
     -log /opt/homebrew/var/log/freeswitch \
     -db /opt/homebrew/var/lib/freeswitch/db \