proxy start -p starts an untracked second proxy and overwrites proxy.pid, so proxy stop kills the wrong one

Summary

portless proxy start -p <port> doesn't check whether the state directory already records a running proxy on a different port. It starts a second proxy and overwrites proxy.pid and proxy.port. The first proxy keeps running, but portless no longer tracks it, and proxy stop -p <first port> then kills the second proxy.

Reproduction (portless 0.15.12, Node 24.19.0, Windows 11, fresh PORTLESS_STATE_DIR)

$ portless proxy start -p 13560 --no-tls
HTTP proxy started on port 13560          # proxy.pid=28956 proxy.port=13560
$ portless proxy start -p 13561 --no-tls
HTTP proxy started on port 13561          # proxy.pid=26712 proxy.port=13561
                                          # both 13560 (28956) and 13561 (26712) listening
$ portless proxy stop -p 13560
Proxy stopped.                            # 26712 killed; 13560 still listening
$ portless proxy stop -p 13560
PID file is missing but port 13560 is still in use.
Killed process 28956. Proxy stopped.

After the second start, list, get, and run follow proxy.port to the second proxy. Routes served by the first proxy are left behind it.

Cause

resolveStateDir() ignores its port argument (cli-utils.ts:409), so every proxy shares one proxy.pid / proxy.port. In proxy start, the check for an already-running proxy through discoverState() only runs when no port is given (cli.ts:3248). With -p, only the requested port is probed (cli.ts:3323). stopProxy then trusts proxy.pid without checking that the PID is the one listening on the requested port.

Expected

proxy start -p B while a tracked proxy is running on A should refuse (or say to stop A first) rather than start an untracked second proxy. proxy stop -p A shouldn't kill a process that isn't listening on A.