fetch() ignores NODE_TLS_REJECT_UNAUTHORIZED, NODE_EXTRA_CA_CERTS and SSL_CERT_FILE — node:https honours all three #9682

Found during #9673's investigation.

perry-stdlib/src/fetch/mod.rs:122 — fetch_client_builder sets no TLS options at all, so fetch() silently ignores NODE_TLS_REJECT_UNAUTHORIZED=0, NODE_EXTRA_CA_CERTS and SSL_CERT_FILE. Meanwhile perry-ext-http/src/tls_client.rs implements all three for node:https — so the two HTTP surfaces disagree, and the one most code reaches for is the one without support.

Practical impact: corporate MITM proxies, self-signed dev endpoints and custom CA bundles all work through node:https and fail through fetch(). (NODE_USE_ENV_PROXY=1 + HTTPS_PROXY does work, so proxying is fine — it is only the trust configuration that is missing.)

Fix: mirror tls_client.rs's handling into fetch_client_builder. Better still, factor the three-variable resolution into one shared helper both surfaces call — this is the same drifted-duplicate-knowledge shape as #9498's dispatch table, and a shared resolver prevents the next divergence.

Also noted from the same session and worth a look while in this area: import * as https from "node:https"; https.request(…) produced no output and no error in a minimal fixture (scratchpad/w9673/t3.ts) — possibly a separate defect.

Verification: fixture hitting a local TLS server with a self-signed cert under each variable, comparing fetch() and https.request() against node's behaviour for all three; plus the negative control that an untrusted cert still rejects when no variable is set.