fix: preserve CONNECT dial errors and request cancellation

[ssharkkky]

1. What does this change do, exactly?

CONNECT currently sends and flushes 200 OK before dialing the target. If the dial then fails, the response status is already committed and the client receives a closed tunnel instead of the connection error. Direct dial failures also fall through to 403 Forbidden, even when an address passed the ACL.

The first commit sends 200 only after a successful dial and flushes it before waiting for target data. Refused connections return 502, timeouts return 504, and ACL denials remain 403. Padding negotiation remains available on error responses.

The second commit carries the request context through DNS lookup and dialing, so cancellation reaches context-aware operations. Connections returned after cancellation are closed. The context remains valid after an upstream proxy dial returns, preserving the lifetime of an established HTTP/2 tunnel.

This intentionally removes the server's optimistic success response. Clients that wait for the CONNECT response now wait for target connection establishment. Address selection and dial timeout settings are unchanged.

Validation with Go 1.22.2:

• New regression cases fail before the corresponding fixes and pass afterward.
• Handler tests cover HTTP/1, HTTP/2, and HTTP/3 failure responses; successful response flushing; ACL rejection; request/DNS cancellation; late successful connections; and upstream context lifetime.
• go build ./..., go test -count=1 ./..., and go test -race -count=1 ./... pass. The full race suite ran in an isolated network namespace to keep its fixed fixture ports separate from concurrent tests.

2. Please link to the relevant issues.

The repository's issue tracker is disabled. CONNECT semantics: RFC 9110, Section 9.3.6.

3. Which documentation changes (if any) need to be made because of this PR?

None; the CONNECT response-order comment is updated with the implementation.

4. Checklist

• I have written tests and verified that they fail without my change
• I made the pull request minimal and added no dependencies
• I have squashed insignificant commits; the two commits separate response handling from cancellation
• Non-obvious behavior is explained in code comments