fix(cli): resolve serve preflight busy pids to an array when discovery returns null

[krzemienski]

Problem

After #14538, omniroute serve crashes on every start where the target port is free and pid discovery can't answer:

✖ Cannot read properties of null (reading 'length')
    at runServe (bin/cli/commands/serve.mjs:261:16)

findListeningPids() returns null when discovery throws, and the bind-probe fallback only reassigns busyPids when the probe finds the port held. On a free port busyPids stays null, and busyPids.length throws.

On macOS this is the normal path, not an edge case: lsof -ti :PORT exits 1 when nothing is listening, execFile rejects on that, and findListeningPids() maps it to null. A launchd KeepAlive install that upgrades to current release/v3.8.51 crash-loops. Reproduced on macOS arm64, Node 22.22.3.

Fix

• New resolveBusyPortPids(port, deps) in bin/cli/utils/pid.mjs always returns an array:
  • the discovered pids when discovery names an owner
  • [] when the bind probe finds the port free
  • [null] when the probe proves the port is held but no owner could be named (keeps the fix(cli): port-in-use guard silently passes when lsof is unavailable (Termux/slim containers) — user gets an EADDRINUSE restart loop instead of the clear message #14518 guard)
• serve.mjs uses it in place of the inline branches. reportPortInUse() and the rest of the preflight are unchanged.

Tests

4 cases appended to tests/unit/cli-serve-port-in-use-preflight.test.mjs: null discovery with a free port gives [], null discovery with a held port gives [null], discovered pids skip the probe, and a real free port with the real lsof gives []. All pass.

Heads-up, unrelated to this change: on macOS, tests 7 and 9 in that file (probePortFree is false while a socket holds the port… and the #14518 end-to-end test) also fail on unmodified release/v3.8.51. probePortFree() binds the dual-stack wildcard, which succeeds while the test's holder is bound to 127.0.0.1 only.

Verified live

Built release/v3.8.51 @ d4bf564, installed it as the global package under launchd, and confirmed the crash loop. With this patch, serve starts cleanly, and /api/health plus chat completions answer 200 locally and through a Cloudflare tunnel.

[diegosouzapw]

Thanks, @krzemienski. The null-discovery crash in the serve preflight was a real issue.

It is already fixed on release/v3.8.51 by #14812: resolveServeBusyPids() now handles findListeningPids() returning null by falling back to a bind probe, and returns [] when the port is free. Since that covers this PR, I'm closing it. Thanks for the report and the fix.