fix(wg+fw): Startup-nftables-Render + /32-Hinweis bei Peer-AllowedIPs

Zwei unabhängige Fixes für das WireGuard peer-to-peer Problem:

1. Startup-nftables-Render: edgeguard-api rendert beim Start die
   nftables-Konfiguration neu. Damit werden Template-Änderungen aus
   einem Update (z.B. 1.1.51 WG-forward-Rule) sofort aktiv, ohne
   dass der Operator manuell eine Firewall-Mutation triggern müsste.

2. UI-Hint: Peer-AllowedIPs-Feld erklärt explizit warum /32 nötig
   ist und was /24 kaputtmacht (Server routet ganzen Subnet-Block zu
   einem Peer → andere Peers nicht mehr erreichbar).

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

cmd/edgeguard-api/main.go

@@ -404,6 +404,19 @@ func main() {
 		// scheduler. StartPeriodicVerification is a no-op when the key
 		// is empty.
 		licClient.StartPeriodicVerification(licKeyStore.Get())
+
+		// Startup-Render nftables: stellt sicher dass Template-Änderungen
+		// aus einem Update (z.B. neue WireGuard forward-Chain-Auto-Regel)
+		// sofort nach dem API-Restart aktiv werden — ohne dass der
+		// Operator manuell eine Mutation triggern müsste. nft -f ist
+		// idempotent und atomar; kein Dienst wird neu gestartet.
+		go func() {
+			ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
+			defer cancel()
+			if err := firewallrender.New(pool).Render(ctx); err != nil {
+				slog.Warn("startup: nftables render failed", "error", err)
+			}
+		}()
 	}
 
 	mountUI(r)