test(providers): isolate environment-proxy test in its own binary

[asiantuntija]

Problem

cargo test -p goose-providers fails deterministically on this machine (12 cores): 65 consecutive runs, 9 failures each.

---- anthropic::tests::fetch_supported_models_propagates_auth_error ----
expected Authentication error, got: NetworkError("Network error — check your network connection and try again.")

---- api_client::tests::loopback_transport_does_not_use_environment_proxy ----
assertion failed: tokio::time::timeout(Duration::from_millis(100), proxy.accept()).await.is_err()

azure_foundry::tests::canonical_claude_deployment_uses_canonical_output_limit also failed on some runs and not others, which is the scheduling dependence showing.

Root cause

loopback_transport_does_not_use_environment_proxy sets HTTP_PROXY/http_proxy process-wide, pointing at a throwaway listener. The env-lock guard serializes it against other env-lock callers, but the wiremock-based provider tests don't use env-lock — they just build clients:

Their helpers call ApiClient::new_with_tls(...), which uses TransportPolicy::Default. Unlike TransportPolicy::LoopbackHttp, that branch never calls .no_proxy().
reqwest reads the proxy environment when the client is built, so requests to the loopback mock server are routed to the throwaway proxy and fail as NetworkError.
That listener then accepts the stray connections, so the proxy test's own "the proxy should never be contacted" assertion fails too.

One env mutation, nine failures. anthropic.rs, ollama.rs, openai.rs, and azure_foundry.rs all use MockServer, so which ones fail on a given run depends on scheduling.

Same class as #11059 (process-global env mutation leaking into parallel tests); this instance is in goose-providers, with HTTP_PROXY rather than GOOSE_PATH_ROOT.

Fix

Move that one test into crates/goose-providers/tests/loopback_proxy_env.rs. Integration test files each get their own process, so the mutation can't reach tests that read it. No production code changes, and no other test needs annotating.

Verification
before: 65/65 runs of cargo test -p goose-providers failed
after: every run green, repeatedly
cargo test -p goose-providers --test loopback_proxy_env passes in its own binary, so the no-proxy behaviour is still genuinely exercised
--no-default-features --features rustls-tls and --features native-tls both pass, matching the CI matrix
cargo clippy -p goose-providers --tests and cargo fmt --check clean

Since CI runs plain cargo test on this crate with no per-test process isolation, this may be surfacing there as intermittent failures — runners have fewer cores, so less of the suite is in flight at once and the overlap is easier to miss.

Alternatives considered

#[serial] on the proxy test doesn't help: serial_test and env-lock are separate locks, so unannotated victims are unaffected — every test that builds an ApiClient would need annotating, effectively serializing the suite. Adding .with_loopback_http_only() to the wiremock helpers would fix today's victims but leaves the trap for future tests.

Found while packaging goose for nixpkgs, where this shows up reliably in the sandboxed build.

Disclosure: analysis and description prepared with assistance from Claude Opus 5 (Anthropic); I reproduced the failure, verified the diagnosis and the fix locally, and reviewed everything here.