spacetime start fails to bind on Windows when WSL port forwarding conflicts exist

[Shiven0504]

Description

When running spacetime start on Windows (native, not WSL), the command fails to start if WSL has previously forwarded the same port. This happens because WSL's automatic port forwarding can hold onto port 3000 even after the WSL session ends, blocking the native Windows spacetime process.

Steps to Reproduce

1. Install SpacetimeDB CLI on Windows using the PowerShell installer
2. Previously run any WSL2 service that used port 3000 (or have WSL auto-forward enabled)
3. Run spacetime start from PowerShell or Git Bash
4. Observe the error: Error: failed to bind to 0.0.0.0:3000

Expected Behavior

spacetime start should either:

1. Detect the port conflict and suggest an alternative port
2. Provide a clearer error message mentioning WSL port forwarding as a potential cause
3. Support a --port flag to specify an alternative port directly

Actual Behavior

The CLI exits with a generic bind error that doesn't help diagnose the WSL-specific issue.

Environment

• OS: Windows 11
• SpacetimeDB CLI version: 2.0.5
• WSL version: WSL 2 (Ubuntu 24.04)

Workaround

# Kill WSL processes holding the port
wsl --shutdown

# Or manually kill the specific port forwarding
netsh interface portproxy delete v4tov4 listenport=3000 listenaddress=0.0.0.0

[Shiven0504]

My suggestion - Add a --port flag that would make local development much smoother for windows users who frequently switch between WSL and native environments. Something like:
spacetime start --port 3001