fix: bind ephemeral server to the loopback address it connects to - #907

Fixes #906

serverAddress() starts the ephemeral server with app.listen(0), which binds the wildcard, and then connects to 127.0.0.1. On macOS the wildcard bind can share its port with another process's 127.0.0.1 listener, and the request goes to that process (#894). #896 fixed this by connecting to ::1, and 71dc5fb moved back to 127.0.0.1 for the Node 26 IPv6 timeout.

This binds the ephemeral server to 127.0.0.1 instead, so the bind and the connection use the same address and IPv6 is not involved at all.

Listening with a host resolves the address asynchronously, so app.address() is still null right after listen(). The request URL is built with the host and path first, and end() fills in the port right before dispatch, which already waits for listening. The host and path are known up front, so the agent's cookie lookup (new URL(req.url) at request creation) keeps working.

Servers that are passed in already listening keep the current behavior.

Testing

• added a regression test that goes through the listen(0) path and checks the bound address. It fails on master (expected '127.0.0.1', got '::') and passes with this change
• npm test on macOS: 137 passing on Node 22.17, 24.11 and 26.10, repeated runs on each