fix: eliminate port race in HTTP-transport e2e tests

[dzianisv]

Fixes the last red CI check (Compile and run tests).

Root cause

The e2e suite failed consistently in CI (every OS/node combo) with Server did not start within 15000ms, yet passed locally. Two bugs:

1. Port TOCTOU race — getFreePort() bound port 0, read the port, closed the socket, returned the number. Under CI's parallel test execution a sibling grabbed the freed port before the spawned server bound it → child hit EADDRINUSE → walked its 1+2+4+8s retry backoff (~15s) → the 15s health-poll timed out.
2. --port 0 fell through to stdio — if (args.port) is truthy, so port 0 never entered HTTP mode.

Fix

Spawn with --port 0 (OS assigns an ephemeral port atomically — never freed/re-grabbed), have the server report the actual bound port via httpServer.address(), and parse it from the server log in the test. Gate HTTP mode on args.port !== undefined.

This is a fork-only test (added in #4 for the Streamable-HTTP multi-agent feature; not present upstream). Validated locally: build + e2e suite + eslint + prettier all green. Relying on CI matrix to confirm the race fix.

🤖 Generated with Claude Code

[dzianisv]

Marking draft. The --port 0 race fix is correct and passes locally, but CI shows the e2e/daemon suite still fails for a deeper, pre-existing CI-environment reason — chrome-devtools-mcp daemon is not running and Windows named-pipe connect ENOENT \\.\pipe\...server.sock at spawnServer. Greening the full e2e/daemon job in CI is a separate infrastructure effort (Chrome setup, daemon lifecycle, Windows IPC, timeouts), not just the port race. Holding until that's scoped.