fix: .env loading no longer overrides already-set environment variables

[mattpodwysocki]

Summary

• .env loading previously applied every key onto process.env with override semantics, so a .env file present in the working directory could take precedence over variables already set by the host process (e.g. MAPBOX_API_ENDPOINT, MAPBOX_ACCESS_TOKEN).
• Extracted the loading logic into src/utils/loadDotEnv.ts and changed it to skip any key that's already set, matching the intent of Node's own process.loadEnvFile(). Already-set keys are now reported in the startup log message and the config.load_env tracing span instead of being silently skipped.

Test plan

• npx vitest run — all tests pass, including new regression tests in test/utils/loadDotEnv.test.ts covering override precedence
• npm run build succeeds
• CHANGELOG.md updated

🤖 Generated with Claude Code

[mattpodwysocki]

Update: pushed a fix for a gap flagged in review of the equivalent mcp-devkit-server PR (mapbox/mcp-devkit-server#138).

The original fix only skipped .env keys that were already set in the process environment. That doesn't help when the host never set MAPBOX_API_ENDPOINT in the first place — the common case, since most operators only set MAPBOX_ACCESS_TOKEN and rely on the built-in https://api.mapbox.com/ default. In that case a malicious .env could still set MAPBOX_API_ENDPOINT, since it was never "already set" to begin with, and the real host-injected access token would still be sent to that attacker-controlled endpoint.

Fixed by making MAPBOX_ACCESS_TOKEN/MAPBOX_API_ENDPOINT off-limits to .env entirely — loadDotEnv now takes a protectedKeys set that .env may never populate, regardless of whether the target env already has a value. A custom endpoint (e.g. an enterprise proxy) still works, but has to come from a real environment variable at the host/launch-config level, not a project-local .env.

Confirmed live both ways: with the prior fix, a tool call with the malicious .env and no host-set MAPBOX_API_ENDPOINT reached the attacker-controlled host; with this fix, the same call reaches the real API (401: Not Authorized - Invalid Token, the expected response for a fake token).

New regression tests cover this exact scenario in test/utils/loadDotEnv.test.ts.