fix(daemon): Robust Windows daemon process management with dynamic ports

[0okay]

PR: Robust Windows Daemon Process Management

The Problem

On Windows, agent-browser uses a TCP port derived from a hash of the session name (default: 50838 for "default"). This leads to several issues:

1. EADDRINUSE Errors: If a daemon process crashes or becomes a zombie without releasing the port, subsequent attempts to start a new daemon fail immediately.
2. Race Conditions: Multiple CLI instances might try to start the daemon simultaneously, causing port conflicts.
3. Connectivity Issues: The CLI often fails to connect with "socket timeout" because it thinks the daemon isn't running (due to missing/stale PID files) but cannot start a new one (due to the port being held).

The Solution

This PR implements a dynamic port allocation strategy for Windows, mirroring the flexibility of Unix domain sockets:

1. Dynamic Port Binding: The daemon now binds to port 0 on Windows, letting the OS assign any available port. This completely eliminates EADDRINUSE conflicts.
2. Port Discovery via File: Once bound, the daemon writes its actual listening port to a .port file in the socket directory.
3. Atomic Discovery: The Rust CLI and JS API have been updated to read the port from this file. If the file exists and a connection can be established, the daemon is considered running.
4. Backward Compatibility: The logic prioritizes the .port file but falls back to the legacy hash-based port if needed, ensuring it works with existing setups.

Changes

• src/daemon.ts: Updated startDaemon to listen on port 0 on Windows and write the result to the port file. Updated getSocketPath and getConnectionInfo to discover the port from the file.
• cli/src/connection.rs: Refactored get_port_for_session to read from the .port file. Updated all connection and health check logic to handle dynamic ports.

Testing

• Verified that multiple sessions can run on Windows without port conflicts.
• Verified that if a process is killed, a new daemon starts on a different port and the CLI picks it up instantly.
• Verified that stale .port files are handled gracefully by the connection retry logic.

[vercel]

@0okay is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.