fix(proxy): skip bare TCP health probe for SOCKS5 data plane

[mdigitalbh81]

Summary

Skip the T14 speculative TCP reachability probe for ordinary SOCKS5 data-plane requests, while preserving the existing HTTP/HTTPS fast-fail behavior and the explicit control-plane direct-fallback probe.

Problem

runWithProxyContext() currently starts isProxyReachable() for ordinary proxied requests. That helper performs a raw net.createConnection() and destroys the socket immediately after TCP connect.

For a SOCKS5 listener this produces a separate connection with no SOCKS payload:

SYN -> SYN/ACK -> ACK -> FIN

In production this shows up as unexpected EOF on the SOCKS/GOST listener, while the real request opens a second connection and performs the actual SOCKS5 greeting + CONNECT flow.

Fix

• skip the speculative T14 probe only for ordinary SOCKS5 data-plane requests
• keep the real SOCKS5 request as the availability signal
• preserve HTTP/HTTPS T14 behavior
• preserve directFallbackOnUnreachable control-plane behavior
• leave background health, dispatcher, retry/fallback, family handling, and SOCKS connector behavior unchanged
• do not introduce socks5h support

Validation

• focused proxy tests: 25/25 passed
• SOCKS/dispatcher tests: 30/30 passed
• npm run typecheck:core: passed
• ESLint: passed
• git diff --check: passed
• commit hooks: passed

Regression coverage verifies that SOCKS5 data-plane traffic no longer invokes the bare TCP probe, HTTP retains the existing fast-fail behavior, real SOCKS failures remain owned by the real transport path, and explicit control-plane fallback still performs its blocking reachability check.

[diegosouzapw]

Good root-cause explanation — the speculative bare-TCP probe against a SOCKS5 listener really
would produce exactly that incomplete-handshake EOF pattern. The fix is narrowly scoped and
your test file (9/9 pass here) explicitly covers the three behaviors you promise to preserve
(HTTP/HTTPS fast-fail, control-plane fallback, real-transport ownership of SOCKS5 failures).
One ask before merge: please add a changelog.d/fixes/ fragment.

[diegosouzapw]

Thanks @mdigitalbh81 — merging via the release merge-train. Validated in local merge-train (merge-train-20260918-120911-suite.log) on the devbox @ train tip 8c305709478b7052fb981a75852bbf88fe3a959d with the sibling PRs of this batch: typecheck:core, file-size, complexity, cognitive-complexity, changelog-integrity green; changed-area node:test 310/311 (the single red, hard-lease inventory, reproduces on the pure release tip) + vitest green (fast parity mode — full suite ran today on the tip via the base-red and 3b trains). Merged --admin per merge-gates §4/§7.