env var overrides for globalArguments silently change which environment a model targets

Description

When a model is configured with globalArguments for a specific environment (e.g., prod-jenkins with baseUrl: http://10.155.16.20:8080), the resolveConnectionOpts pattern of falling back to env vars like JENKINS_BASE_URL makes it possible to accidentally run a prod-named model against dev infrastructure (or vice versa).

This is risky because:

• Swamp data artifacts are stored under the model name, so prod-jenkins data would contain dev results
• It's not obvious from the command invocation which environment is actually being targeted
• Workflows referencing data.latest("prod-jenkins", ...) would get contaminated data

Expected Behavior

Users should create a separate model per environment (e.g., prod-jenkins, dev-jenkins) rather than overriding globalArguments via env vars. Swamp could help enforce this by:

• Warning when env vars override model globalArguments
• Providing a --env flag on model method run that selects a pre-configured environment variant
• Documenting the one-model-per-environment pattern as a best practice

Steps to Reproduce

1. Create a model prod-jenkins with baseUrl: http://prod:8080
2. Run JENKINS_BASE_URL=http://dev:8080 swamp model method run prod-jenkins listPlugins
3. Data artifacts are stored under prod-jenkins but contain dev data

Environment

• swamp version: 20260318.021802.0-sha.3848499d
• OS: macOS Darwin 25.3.0