The firewall verbs name the rule from darling.json's port while the endpoint binds the store's #2414

Found while working #2389, which fixed the diagnostic for the same split. This one is a functional consequence and deserves its own lane.

mcp.port / web.port are control-plane-authoritative once the store is seeded — the supervisor resolves config_service.mcp_port and binds Kestrel there. But every firewall surface derives the rule name and the port from darling.json:

• DarlingCliCommands.ReconcileEndpointFirewallAsync (the firewall half of --enable-mcp / --disable-mcp / --enable-web / --disable-web) — McpFirewallRuleName(config.Mcp.Port), config.Mcp.Port
• --configure-firewall's plan builder — same two, for MCP and web alike

The runtime side does not. DarlingMcpHostService calls CheckMcpFirewallAsync(effectivePort, …), where effectivePort is the store's port.

The failure

Toggle the MCP port in the Viewer's Settings (5152 → 5199) on a box with an mcp.network block:

• the endpoint rebinds to 5199 within one poll interval, correctly, no restart
• the service then looks for PerformanceMonitor Darling MCP (port 5199) and reports it missing
• an admin runs --configure-firewall as instructed, and it creates/keeps PerformanceMonitor Darling MCP (port 5152) for port 5152 — the wrong rule, from the stale file value, and it will keep creating that one however many times it is run
• the exposed endpoint has no firewall path; LAN clients are blocked, loopback still works, so it reads as a client or CIDR problem

The stale rule for 5152 also stays open on a port nothing is listening on, which is the opposite of what the scoping is for.

Same shape for the web dashboard.

Why it survived

Nothing agrees or disagrees until someone changes the port in the store, which is rare — and when it happens the symptom (LAN clients can't connect, loopback can) points at the CIDR or the token, not at a rule name. #2389 now warns when the two ports disagree, so the precondition is at least visible, but the elevated verb still writes the wrong rule.

Options

1. Give the firewall verbs the store's port. ToggleEndpointAsync already builds an owner connection from the DPAPI credential a few lines earlier, so for --enable-mcp/--disable-mcp the read is nearly free — resolve the effective port the same way the supervisor does and name the rule for it. --configure-firewall would need the same connection added, and a defined answer for an unreachable store (fall back to the file value and say so, rather than silently).
2. Reconcile by prefix rather than by exact name — enumerate PerformanceMonitor Darling MCP (port *) and remove the ones that do not match the effective port. Fixes the stale-rule half regardless of which port the verb was told about.
3. Refuse and explain when the file port and the store port disagree, pointing at the store value — cheapest, and consistent with the fail-closed posture elsewhere, but it leaves the operator to run something else.

What should decide

Whether --configure-firewall is allowed to require a reachable store. It runs elevated at install time, possibly before the store exists, so option 1 alone may not be available to it — which argues for 1 + 2 together (authoritative port when the store answers, prefix cleanup either way), or 3 as the floor.

Not a security hole: it fails closed (the port is unreachable rather than over-exposed), and the token + in-app CIDR are the boundary, not the firewall. It is a correctness and wasted-afternoon problem.