derp/derphttp: honor DERPNode.DERPPort in proxied CONNECT dial

[mzihlmann]

Cherry-pick of tailscale#19752 (fixes tailscale#19748) onto coder's fork.

When derphttp.Client routes a DERP connection through an HTTPS forward proxy (HTTPS_PROXY), the CONNECT request always targets port 443, even when the DERP map specifies a custom DERPPort.

The non-proxy path, dialNode, derp/derphttp/derphttp_client.go#L909-L913, correctly honors n.DERPPort:

port := "443"
if n.DERPPort != 0 {
    port = fmt.Sprint(n.DERPPort)
}

The proxy path, dialNodeUsingProxy, same file L993, hardcodes "443" and never consults n.DERPPort:

target := net.JoinHostPort(n.HostName, "443")

A custom DERP server on a non-443 port is therefore unreachable through HTTPS_PROXY: the CONNECT line is sent to host:443, the proxy faithfully tunnels to whatever sits on :443 at that hostname/IP, and TLS either fails on cert validation (if a different service runs on :443) or talks to the wrong service.

This PR mirrors dialNode's port selection in dialNodeUsingProxy. The end-to-end test from the upstream PR doesn't port cleanly (this fork lacks feature.HookProxyFromEnvironment, renamed/narrowed types) and the unit-test variant was dropped on the upstream PR (commit bb8b711), so this PR is fix-only.

[mzihlmann]

I think failure is unrelated, no?

[mzihlmann]

CI failures here are pre-existing on main (staticcheck + the cross (...) build-tests jobs all fail with the same compile errors in github.com/aws/aws-sdk-go-v2/feature/s3/manager@v1.11.64 against the newer service/s3 pulled in by #111). Fix is in #121 — once that lands and this branch is rebased, CI should go green.

[deansheather]

Yeah CI is broken on our fork, the main thing we care about is tests on Linux. Thanks for the contribution!