fix(daemon): actionable error when the WS port is in a Windows excluded range

[captainhuke-dev]

Summary

On Windows, TcpListener::bind fails with WSAEACCES (os error 10013) when the port falls inside a dynamically-excluded range reserved by Hyper-V, WSL, or WinNAT. The default port 52800 can land in such a range, in which case bsk daemon start failed with a bare 'access forbidden' and no hint.

This change detects the PermissionDenied bind failure and translates it into an actionable message: it names the port, explains the excluded-range cause, and points to netsh interface ipv4 show excludedportrange protocol=tcp, bsk daemon start --port <port>, and the extension popup (the extension connects to the port stored in the popup, not the one in daemon.json, so the two must match).

Why not auto-pick a port

The extension connects to a user-stored port (default 52800) and never reads daemon.json or scans ports. A silent daemon-side port fallback would start the daemon on a port the extension does not dial, leaving 'daemon running but extension cannot connect'. Detection + an actionable error is the safe fix; auto-recovery is a larger protocol change (extension-side discovery) and is out of scope here.

Verification

• cargo test -p bsk --lib — all daemon::ws tests pass, including two new unit tests (Windows translation + leaving other bind errors untouched).
• cargo clippy -p bsk --lib — no new warnings (3 pre-existing in unrelated files).
• cargo +stable fmt -p bsk --check — clean.
• End-to-end on Windows x64 (GNU toolchain build):
  • default port 52800 (inside an excluded range) -> new actionable message, exit 2
  • port already in use (os error 10048) -> original 'address in use' context preserved
  • free port -> normal daemon ready success path unchanged

Files

• crates/bsk-cli/src/daemon/ws.rs — bind-error translation + unit tests
• docs/architecture.md — troubleshooting note