Restore override loading; fix multi-repo workflow regression

Non-override loading broke fetch-all and generate-all: the first env
file's REPO_OWNER/REPO_NAME/GITHUB_TOKEN would persist across all
subsequent iterations. Explicit --env-file is always authoritative.

When using `op run --env-file=<f>`, secrets are resolved to real values
before the process starts, so override mode is safe there too.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: pront

scripts/util/load_env.py

@@ -26,7 +26,7 @@ def load_env(env_file=ENV_FILE) -> dict:
         if not env_file:
             raise ValueError(f"No .env file found at {env_file}")
 
-    success = load_dotenv(env_file, override=False, verbose=True)
+    success = load_dotenv(env_file, override=True, verbose=True)
     if not success:
         raise ValueError(f"Failed to load .env file at: {env_file}")
 

src/config.rs

@@ -20,8 +20,11 @@ impl Config {
 impl Config {
     pub fn load(env_file: Option<&str>) -> Result<Self> {
         if let Some(path) = env_file {
-            // Non-override: vars already in the environment (e.g. injected by `op run`) take precedence.
-            dotenvy::from_filename(path)
+            // Override: an explicit --env-file is authoritative, which is required for
+            // multi-repo workflows that iterate over several env files in sequence.
+            // When using `op run --env-file=<f>`, secrets are resolved before this
+            // process starts, so the file values are already the real ones.
+            dotenvy::from_filename_override(path)
                 .with_context(|| format!("Failed to load env file: {path}"))?;
         } else {
             dotenvy::dotenv().ok();