feat: add connectTimeout option for TCP connection timeout

[pabloelisseo]

Summary

Adds a new connectTimeout option that sets a timeout for the TCP connection handshake phase,
separate from the existing proxyTimeout (which handles idle socket timeout after connection).

Closes #48

Problem

When proxying to an unreachable target (firewall drops packets, non-existent host), the proxy
hangs for 75-130 seconds waiting for OS-level TCP timeout. The existing proxyTimeout only
fires after connection is established.

Solution

Listen for the socket event on the proxy request and set a timer that destroys the socket
if connect doesn't fire within the specified time.

const proxy = createProxyServer({
target: 'http://example.com',
connectTimeout: 10000, // Fail fast if can't connect within 10s
});

Testing

Added tests for:

• ✅ Timeout fires when target is unreachable
• ✅ No timeout when connection succeeds quickly
• ✅ Timer is properly cleaned up on success/error/close

Notes

• For the fetch/HTTP2 path, connection timeout should be configured via undici Agent's
  connect.timeout option (documented in README)
• Error code is ECONNECT_TIMEOUT to distinguish from ETIMEDOUT (OS-level) and
  ECONNRESET

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f46c7df564

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Skip connect timeout on already-connected sockets

connectTimeout is armed on every proxyReq socket, but on keep-alive reuse the connect event does not fire. In that case the timer will expire after connectTimeout and call socket.destroy(err) while a valid, already-established connection is carrying the request, causing intermittent failures whenever connection pooling is enabled. This only happens when connectTimeout is set and the agent reuses sockets; consider checking socket.connecting (or clearing immediately when it’s false) so the timeout only applies to the TCP handshake.

Useful? React with 👍 / 👎.