fix(wg+fw): Peer-Sync-Bug via sudo-Symlink + Site-to-Site-Masquerade

- WireGuard-Peer-Änderungen landeten nicht im laufenden Interface:
  /etc/wireguard/ ist root:root 700, os.Readlink schlug fehl →
  ensureWGQuickSymlink fiel immer in den Error-Pfad. Fix: Symlink
  via sudo /bin/ln -sf (sudoers-Entry in postinst ergänzt).

- Site-to-Site-Masquerade: Roadwarrior-Clients (z. B. 192.168.99.3)
  konnten LANs hinter anderen Peers nicht erreichen, weil das remote
  Gateway die VPN-Client-IP nicht als Tunnel-Route kannte. Fix: auto
  masquerade in nftables postrouting_nat pro WireGuard-Server-Interface
  (oifname "wg7" ip saddr 192.168.99.0/24 masquerade).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

internal/firewall/ruleset.nft.tpl

@@ -138,6 +138,16 @@ table inet edgeguard {
         # client-IP (für Logging / Geo-Block: später optional via
         # NAT-Rule-Flag preserve_client_ip).
         ct status dnat masquerade
+
+        # Auto-Masquerade für WireGuard site-to-site: VPN-Clients (z. B. Roadwarrior
+        # mit 192.168.99.3) greifen auf LANs hinter anderen Peers zu (z. B. 10.0.10.0/24).
+        # Das entfernte Gateway (z. B. Unify Home) sieht als Return-Destination die
+        # VPN-Client-IP — die es nicht in seiner Routing-Table hat → Reply wird gedroppt.
+        # Masquerade schreibt die Source auf die lokale Tunnel-IP um; Return-Traffic
+        # findet so den Weg zurück durch den Tunnel.
+{{range .WGSiteMasq}}
+        oifname "{{.Iface}}" ip saddr {{.VPNNet}} masquerade comment "auto: WireGuard site-to-site masquerade {{.Iface}}"
+{{end}}
 {{range .NATRules}}{{if eq .Kind "snat"}}
         # NAT {{.ID}} (snat{{if .Comment}} — {{.Comment}}{{end}})
         {{""}}