feat(config): add conflict detection warnings when env vars override user-configured settings

[reidliu41]

Summary

Phase 3 of config unification (#1119). After Phase 1-2 established the
env > settings > default resolution chain, users still get no feedback
when an env var silently overrides a value they explicitly set via
config set or TOML — leading to confusion when settings appear to
have no effect.

• Add warn_if_env_shadows() helper that detects when an env var overrides a non-default setting value
• Warn when HTTP channel is implicitly enabled by HTTP_PORT/HTTP_HOST env var despite http_enabled=false in settings
• Warn when both TUNNEL_URL and TUNNEL_PROVIDER are configured (managed provider may overwrite static URL)
• Warn when both heartbeat fire_at and interval_secs are set (interval_secs is silently ignored)
• Add env-vs-settings override detection for key fields in wasm, sandbox, builder, and safety modules
• Pure tracing::warn() additions — no changes to resolution logic or final config values

Ref #1119

Change Type

• Bug fix
• New feature
• Refactor
• Documentation
• CI/Infrastructure
• Security
• Dependencies

Linked Issue

Validation

• cargo fmt
• cargo clippy --all --benches --tests --examples --all-features
• Relevant tests pass:
• Manual testing:

Security Impact

Database Impact

Blast Radius

Rollback Plan

---

Review track:

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[reidliu41]

Hi team, can someone help to review? thanks

[ilblackdragon]

Compatibility note: PR #1340 split priority model

PR #1340 (custom LLM provider config via web UI) has changed the resolution priority for LLM settings only to DB > env > default. All other subsystems (the ones this PR covers) still use env > settings > default.

This PR's warn_if_env_shadows() approach is correct for the subsystems it touches — they all still have env-first priority. The warning direction ("env var overrides user-configured setting") is appropriate.

Note that #1340 already added a complementary warning in src/config/llm.rs for the opposite direction: when a DB-persisted llm_backend overrides a LLM_BACKEND env var. So the two PRs are complementary — this one covers non-LLM subsystems, #1340 covers LLM.

No conflicts — this PR can proceed as-is once #1340 is merged. Just be aware that the priority model is now split, so any future warn_if_env_shadows calls added to LLM-related config would need the opposite warning direction.

[reidliu41]

just updated