Quality gates / quality (pull_request) Waiting to run
The harness derived every server port from a fixed `nextPort = 43100`, which lives inside this host's ephemeral range (32768-60999). The kernel can already have handed one of those numbers to an unrelated outbound socket — a Caddy -> Gitea connection held 43102 — so the spawn died with EADDRINUSE before a single assertion ran, and the suite reported a failure for a reason that is not the code under test. Reproduced 3/3 on main; 6/6 with the block moved out of range. Ports now come from a bind on :0, readiness is the child's own "Timmy is listening on http://" line rather than a poll deadline, and a port stolen in the probe-then-spawn gap is retried (4 attempts) instead of failing the release. Hold-out: with the leading-slash branch of resolveBasePath disabled, the gate still fails in ~336 ms with "the server announced it was listening" — the retry cannot make a broken validator pass.