Claude Desktop picker route test releases its port pair before listeners start #6014

Summary

tests/claude-integration/claude-desktop-picker-routes.test.ts discovers a consecutive CONNECT/picker port pair by binding probe servers and closing them before startPicker() creates the real runtime listeners. The released values are observations, not reservations. Another listener can claim either port in that gap, including the fixture's own ephemeral TLS listener.

Confirmed failure

Exact-head CI for PR #6006 failed in run 36279714238, test 1/4:

• startPicker logged listen EADDRINUSE: address already in use 127.0.0.1:42429;
• runtime correctly cleared the unavailable picker/controller;
• the management route therefore returned 503 instead of the test's intended controller-policy 409;
• fix(claude): validate translated strict output schemas #6006 does not modify the picker/runtime/test fixture files.

Root cause

The fixture's freePortPair binds and closes probes for p and p+1. Runtime startup then creates a separate TLS listener on port 0 before binding the fixed CONNECT and picker ports. Because the probes have already closed, none of the three ports is reserved during startup. The exact process that occupied the failed port is not logged, so this issue does not claim a confirmed external versus self-collision; either is admitted by the same fixture gap.

Required fix

Replace probe-and-release allocation with a fixture seam that keeps ownership deterministic through listener startup, or inject already-created/reserved listeners/ports so the runtime cannot reuse the picker port. Preserve production binding behavior. Add a regression that exercises the intended callerAddedTrust refusal path without depending on a released consecutive port pair.

Do not paper over the race by retrying the 503 assertion: the test is meant to prove the controller's 409 policy and trust cleanup, not listener-unavailable behavior.