feature: language toolchains and scripted HTTPS clients keep working

Feature Description

A different failure mode from the git/gh/ssh case. These tools do not use the OS trust store,
so each needs its own CA environment variable, and the semantics differ per tool.
cmd_claudecode.go already documents the matrix: NODE_EXTRA_CA_CERTS extends the trust
store so it gets ca.crt, while SSL_CERT_FILE (Go: gh, abctl), GIT_SSL_CAINFO (git,
including the fetches go mod makes), REQUESTS_CA_BUNDLE (Python requests) and
CURL_CA_BUNDLE replace it, so they get bundle.crt — get that wrong and every unproxied
TLS call fails.

The gap: those variables are written into Claude Code's settings.json env block, so they
only reach processes Claude Code spawns. A tool the user runs in their own shell gets none of them.

Proposed Solution

• Go module fetch / go get, gh, and other Go CLIs run directly by the user
• npm / pnpm (Node), pip / uv (Python requests)
• curl and wget, with and without proxy env set
• Shell scripts inheriting HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY
• macOS Go gap: SSL_CERT_FILE is inert on darwin — Go resolves roots through
  Security.framework and reads no files, so a Go tool cannot be pointed at a CA file by
  environment at all. Decide the supported answer (keychain install, or documented
  limitation) rather than leaving darwinGoNote as the only mitigation
• Document the intended behaviour per tool: proxied, passed through, or unsupported
• Unsupported combinations fail with an actionable message, never intermittently

Additional Context

Part of the Cortex v0.9.0 release. Gates exit criterion 2 (Cortex is invisible to everything else).