feat(http): honor HTTP_PROXY/HTTPS_PROXY/NO_PROXY on login and submit

[rudi193-cmd]

Summary

Whole of #83: proxy dispatcher (slice 1), named reach-failure classes (slice 2), docs/corporate-networks.md (slice 3).

• Slice 1: Node's fetch ignores proxy env vars. http-client.ts attaches a lazy module-level undici EnvHttpProxyAgent when HTTP_PROXY/HTTPS_PROXY/http_proxy/https_proxy is set. Unset → dispatcher-less fetch. NO_PROXY is honored by the agent after it exists; it does not attach the agent. scan still has no network. headRequest/getJson stay fail-open.
• Slice 2: thrown NetworkError only. Class from error.code / cause.code (never error.message, headers, or body):
  • TLS/cert codes and UND_ERR_PRX_TLS → could not verify TLS certificate (corporate proxy? see docs/corporate-networks.md)
  • HTTP 407, or CONNECT tunnel not 200 (UND_ERR_ABORTED in undici 6.28.0) → proxy required
  • ECONNREFUSED → connection refused
  • else Could not reach <host>.
• Slice 3: proxy env vars, NODE_EXTRA_CA_CERTS, captive-proxy visibility probe.

Dependency justification

• Package: undici@6.28.0 (exact pin).
• What it does: EnvHttpProxyAgent implements HTTP_PROXY/HTTPS_PROXY/NO_PROXY for fetch's dispatcher.
• Why the existing stack can't: Node 20/22 do not expose ProxyAgent/EnvHttpProxyAgent from the bundled undici, and the native env-proxy flag is Node 24+ (above engines.node >= 20). Hand-rolling CONNECT over node:http is more security-sensitive for less correctness (jpbelmo on Corporate proxy support + network errors that tell you what happened #83).
• Supply chain: undici is the Node.js core team's fetch implementation — the same code already running inside every supported Node. No install scripts. Exact pin, not a range.
• Why 6.28.0 not 8.x: undici 8 requires Node >=22.19; 6.28.0 is >=18.17 and matches this repo's Node 20 floor.

Privacy gate: run

• Boundary question: YES — prior issue Corporate proxy support + network errors that tell you what happened #83 (network path for login/submit only; no new destinations, no new payload fields). Error strings are a closed set plus host; they do not echo error.message, headers, or body.
• npm test / tsc: green (895 tests after rebase onto 0.13.0, tsc --noEmit).
• Sweeps: undici added to package.json (justified above). No postinstall. undici import confined to http-client.ts (privacy test). Classification uses error.code only.

Test plan

• HTTP_PROXY unset → fetch init has no dispatcher
• HTTP_PROXY or HTTPS_PROXY set → fetch init has dispatcher; one agent reused across calls
• ECONNREFUSED / TLS cause.code / HTTP 407 / UND_ERR_ABORTED / UND_ERR_PRX_TLS → closed class strings; planted tokens in error.message and 407 bodies stay out
• test/privacy/zero-network.test.ts green
• Maintainer: reviewer pass on the new dependency pin and undici 6.28.0 codes

[jpbelmo]

This is how a first-ever dependency should land: exact pin, integrity verified, no install scripts, honest justification, and you even wrote the privacy test that cages undici inside http-client. The engines homework on 6.x vs 8.x was exactly right.

One change before merge: the PR says the agent is constructed once, but the code builds a new EnvHttpProxyAgent() on every cliFetch call. During login's device-flow polling that's a fresh agent (and connection pool) per poll, none ever closed — under a proxy that can also keep the process alive on lingering sockets after success. Make it a lazy module-level singleton (agent ??= new EnvHttpProxyAgent()) and the code matches your own description.

Two notes, no action needed: the CHANGELOG will conflict trivially with main's new [Unreleased] (I'll resolve at merge), and nice drive-by on the stale lockfile version. Slices 2-3 whenever you want them.

[rudi193-cmd]

Pushed c629167: cliFetch now uses a lazy module-level singleton (agent ??= new EnvHttpProxyAgent()). Device-flow polls share one agent/pool instead of allocating a new one each tick.

Test added: two postJson calls with HTTP_PROXY set pass the same dispatcher object.

[rudi193-cmd]

Slices 2 and 3 are on this PR (129d15d), per the review note.

Slice 2. Thrown NetworkError only. Class from error.code / cause.code / AggregateError errors, plus HTTP 407 — never error.message, headers, or body:

• TLS/cert codes → could not verify TLS certificate (corporate proxy? see docs/corporate-networks.md)
• ECONNREFUSED → connection refused
• UND_ERR_PROXY or 407 → proxy required
• anything else stays Could not reach <host>.

I did not map no-proxy ECONNREFUSED to proxy required — that would be a guess. headRequest / getJson still fail open. Tests plant a token in error.message and a 407 body and assert neither appears.

Slice 3. docs/corporate-networks.md: proxy env vars, NODE_EXTRA_CA_CERTS, captive proxy answering 200 on the visibility probe.

Privacy gate: prior issue #83. npm test 884 passed. No new dependency in this commit. http-client.ts still the only undici import.

[jpbelmo]

Two things at once here. First: the classification design is exactly right — codes only, never runtime messages, closed strings with host as the only interpolation, and the non-leakage tests per class are the kind of paranoia this repo runs on. Second: you shipped slices 2-3 into a PR whose body still says they're not in it, thirteen minutes after the approval that covered slice 1. I get the momentum, but scope that arrives after review is scope nobody reviewed — next time push it as its own PR or say so on the thread first. It cost you nothing this time because the review found the gaps quickly:

1. UND_ERR_PROXY doesn't exist in undici 6.28.0. Its proxy errors are UND_ERR_PRX_TLS (TLS through the proxy) and a CONNECT-tunnel 407 surfacing as UND_ERR_ABORTED. So your "proxy required" class never fires on the most common corporate case (auth proxy on HTTPS tunnel) — it falls to the generic message. Rework the branch against the real codes, add UND_ERR_PRX_TLS to the TLS class as a safety net, and add a test for whichever branches remain: the dead branch slipped through precisely because it's untested.
2. docs/corporate-networks.md repeats the phantom UND_ERR_PROXY claim, and lists NO_PROXY as if it alone attached the agent (proxyEnvSet() only checks HTTP(S)_PROXY variants). Fix both.
3. Update the PR body: it currently disclaims the slices it now contains, and the privacy-gate section describes only slice 1.

With those three, the whole of #83 lands in one PR and it's a good one.

[rudi193-cmd]

Review points 1–3:

1. Dropped the phantom UND_ERR_PROXY. undici 6.28.0: CONNECT not-200 (including 407) is UND_ERR_ABORTED → proxy required; UND_ERR_PRX_TLS is in the TLS class. Tests for both, plus the existing HTTP 407 path.
2. Docs: NO_PROXY does not attach the agent; only HTTP(S)_PROXY variants do. Phantom code name removed.
3. PR body updated for all three slices.

Rebased onto main (0.13.0) so the CHANGELOG conflict is gone.

[jpbelmo]

Merged: the whole of #83 in one PR, and the classifier came out the way this repo likes its network code: codes only, closed strings, every branch tested with planted secrets asserted absent. Verified your undici claims against the installed package source — all exact. First dependency in the repo's history and it set the bar. Corporate users owe you one.