refactor(environments): split mod.rs into config/devx_core/catalog submodules

[jpage-godaddy]

Summary

• environments/mod.rs was approaching the 1000-line CI limit, blocking contributors adding to it in an open PR and another in-progress branch.
• Split by responsibility rather than by command (this module isn't command-tree-shaped): config.rs (GddyEnvConfig + URL resolution/derivation helpers), devx_core.rs (DevX Core gateway URL resolution), catalog.rs (API-catalog domain base-URL resolution), and test_support.rs (shared test-only env-var guard, #[cfg(test)]-only).
• mod.rs now holds only the compiled-in ote/prod registry, the shared Environments singleton, and the public resolve/listable/is_known API.
• Public API is unchanged (re-exported from mod.rs), so every existing crate::environments::* call site is untouched.

Test plan

• cargo check passes
• cargo clippy -- -D warnings passes with zero warnings
• cargo test passes (615 passed, same 36 environments-module tests as before, moved verbatim)
• cargo fmt --check is clean
• ./rust/scripts/check-module-size.sh passes (largest new file is 503 lines)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Refactors the rust/src/environments module by splitting the previously large mod.rs into focused submodules while keeping the public crate::environments::* API unchanged. This supports continued growth of environment/URL-resolution logic without hitting the CI 1000-line file limit.

Changes:

• Split environment responsibilities into config, devx_core, and catalog submodules, with mod.rs retaining the shared Environments singleton and public entrypoints.
• Centralized test-only env-var helpers into test_support.rs for reuse across submodules.
• Moved existing tests alongside the code they validate (e.g., DevX Core and config URL resolution tests).

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
rust/src/environments/mod.rs	Introduces submodules and re-exports; keeps the main public environment registry/singleton and top-level APIs.
rust/src/environments/config.rs	Holds GddyEnvConfig and shared URL validation/derivation helpers, plus associated tests.
rust/src/environments/devx_core.rs	Extracts DevX Core gateway URL resolution and its tests.
rust/src/environments/catalog.rs	Extracts API-catalog domain base-URL resolution and its tests.
rust/src/environments/test_support.rs	Adds shared test-only env-var locking + RAII env-var restore helper for env-var-touching tests.

Suppressed comments (1)

rust/src/environments/catalog.rs:93

• This test calls resolve_catalog_base_url, which reads process env vars via std::env::var. Because other tests in this module mutate env vars using EnvGuard/set_var, this should take ENV_LOCK to avoid concurrent env access during those unsafe writes (and to prevent cross-test flakiness).

    fn resolve_catalog_base_url_applies_convention_for_non_prod() {

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (1)

rust/src/environments/test_support.rs:25

• EnvGuard::set relies on a caller-held ENV_LOCK for safety, but the API doesn’t enforce that invariant. It’s easy for a future test to call EnvGuard::set(...) without holding the lock, reintroducing cross-test flakiness and potential UB (since std::env::set_var/remove_var are unsafe). Consider encoding the lock requirement in the API (e.g., have EnvGuard::set take a &MutexGuard<()>, or have EnvGuard::set acquire and hold the lock internally) so misuse is impossible.

impl EnvGuard {
    pub(super) fn set(key: &'static str, value: &str) -> Self {
        let prior = std::env::var(key).ok();
        // SAFETY: caller holds ENV_LOCK.
        #[allow(unsafe_code)]
        unsafe {