fix(paths): avoid Windows-excluded dynamic ports for daemon endpoints

[zackees]

Context

fbuild 2.5.17 cannot start its daemon on this Windows host because the deterministic endpoint maps into a TCP exclusion range reserved by Windows/Hyper-V.

Observed with the current main binaries:

• fbuild-paths::default_daemon_port() resolves the dev endpoint to 49785.
• netsh interface ipv4 show excludedportrange protocol=tcp and the IPv6 equivalent both include 49690-49789 (followed by adjacent reserved blocks through 50459).
• No process is listening on 49785.
• A direct TcpListener bind to 0.0.0.0:49785 fails with WSAEACCES / native error 10013.
• fbuild-daemon retries three times and exits; the CLI then repeats three 10-second readiness attempts and reports daemon did not become healthy after 3 spawn attempts.

Exact fbuild log:

bind to 0.0.0.0:49785 failed (An attempt was made to access a socket in a way forbidden by its access permissions. (os error 10013)); no listener present (stale state)

Control: setting FBUILD_DAEMON_PORT to a free port (62796 in this run) lets the same merged CLI/daemon start, complete clean sketch ... -e esp32dev, and stop normally.

Root cause

crates/fbuild-paths/src/lib.rs::port_from_endpoint_key intentionally maps every default endpoint into the IANA dynamic window 49152-65535. On Windows, that is also the default ephemeral allocation window and Hyper-V/HNS commonly reserves blocks inside it. A deterministic hash can therefore select a port the kernel rejects even when no listener exists. The daemon's bind retry treats the permanent access denial as transient stale TCP state, so retries cannot recover.

Proposal

On Windows, map endpoint keys into a deterministic user-space window below the default dynamic/exclusion range (for example 10000-49151), while retaining endpoint-key isolation and the explicit FBUILD_DAEMON_PORT override. Keep the existing dynamic mapping on platforms where it is not subject to Windows exclusion blocks.

Update the path contract/docs and add pure regression coverage proving Windows-derived defaults stay below 49152 while remaining deterministic and nonzero.

Acceptance criteria

• The current dev endpoint no longer resolves to excluded port 49785 on Windows.
• Default Windows daemon ports are deterministic per endpoint key and fall below the default Windows dynamic/exclusion range.
• FBUILD_DAEMON_PORT retains highest priority and is unchanged.
• Version/cache-identity endpoint isolation from daemon: endpoint isolation follow-up to #940 — key the default endpoint by cache-identity/checkout + deterministic version arbitration #1009 remains intact.
• The original no-override startup and clean sketch command succeed on the affected host.
• Focused path tests, fbuild CLI/daemon tests, formatting, and lint are green.

Decisions made

• Treat this as endpoint selection, not firewall or stale-daemon recovery: the kernel independently rejects the port and an explicit free port succeeds.
• Do not change or delete Windows port exclusions; they belong to the OS/network stack.
• Keep non-Windows port behavior unchanged to minimize endpoint churn.
• No strong duplicate was found. daemon: endpoint isolation follow-up to #940 — key the default endpoint by cache-identity/checkout + deterministic version arbitration #1009 introduced endpoint hashing and daemon: concurrent fbuild invocations stampede daemon spawn — add single-flight + bind before heavy init #1010 added bind retry/single-flight, but neither handles OS-excluded ports with no listener.