fix(web): retain browser-compatible listen ports

[outlier27-cell]

Problem

Closes #694. Web Host could retain an OS-assigned or explicitly configured port that Fetch blocks (for example 6000), publish readiness, and leave the workbench unreachable. An isolated TCP/Fetch reproduction and a full Windows test run demonstrated the failure.

Value

Automatic startup no longer intermittently selects an unusable browser port; an explicit blocked port gets an actionable diagnostic.

Approach

Retain the loopback listener only after checking the WHATWG Fetch blocked-port list. Reject explicit blocked ports and close/retry automatic allocations at most eight times. Preserve original bind errors and clean temporary listeners on success, failure and exhaustion. Durable source evidence: docs/research/WEB_BROWSER_PORT_2026-10-07.md.

Validation

• Five deterministic transport regressions pass, including a real Fetch request after a forced blocked allocation, bounded exhaustion, occupied-port errors and synchronous-error cleanup.
• bun run check: passed.
• bun run test: executed; 2181 passed, 12 failed, 14 skipped in the local Windows Node suite. Failures concern renderer/footer contracts, symlink EPERM and a worktree-validation timeout; no browser-port regression failed. The runner stopped before the UI suite, so a full local pass is not claimed. Exact-head GitHub CI will validate isolated environments.
• No live model or installed Pi/browser acceptance is claimed.

Impact

User-visible startup diagnostics and automatic port selection change. No model-facing tools/context, persisted data/configuration or permissions change. Startup retries are bounded and never widen loopback binding. Occupied explicit ports still fail instead of silently switching ports.