Firewall auto-configure fails Access-denied on every service start; a fresh networked install would be blocked outright #1771

On a production field instance, EVERY service start logs both halves of the firewall self-heal failing for BOTH ports (5152 MCP, 5153 Web):

[DarlingMcpHostService] Could not remove the firewall rule automatically (exit 1: Remove-NetFirewallRule : Access is denied...)
[DarlingWebHostService]/[DarlingMcpHostService] Could not configure the firewall automatically (exit 1: New-NetFirewallRule : Access is denied...)

Harmless on that box only because the rules already exist from earlier manual setup. On a genuinely fresh install with no pre-existing rules, the service account cannot create the rule it needs, so networked MCP/Web access would presumably be blocked outright - and networked is the normal deployment mode, not the exception. At minimum it is guaranteed log noise on every start of every hardened install.

Root cause shape: firewall rule management requires elevation the service account does not have (by design - it should not have it). A runtime self-heal from a non-admin service identity is structurally the wrong place for this.

Fix direction: move firewall rule creation/repair to the ELEVATED context that already exists - service installation/registration time (the install path runs elevated to register the service; create the two rules there, idempotently, and remove them on uninstall). The runtime path then degrades to a CHECK: if the expected rule is absent, log one clear WARN naming the exact New-NetFirewallRule command an admin should run, instead of attempting it and failing with access-denied noise every start.