process.loadEnvFile() does not override existing environment variables

### Version v24.14.0 ### Platform ```text Darwin telsha 25.4.0 Darwin Kernel Version 25.4.0: Thu Mar 19 19:31:09 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T8132 arm64 ``` ### Subsystem _No response_ ### What steps will reproduce the bug? 1. Create two files: `.env` with `KEY=original` and `.env.test` with `KEY=override`. 2. Run the following in the Node.js REPL: ```javascript // Load the first file process.loadEnvFile(".env"); console.log(process.env.KEY); // 'original' // Attempt to load the second file to override the value process.loadEnvFile(".env.test"); console.log(process.env.KEY); // Still 'original' ``` Mitigation: ```javascript import { parseEnv } from 'node:util'; import { readFileSync } from 'node:fs'; // This forces the override const integConfigs = parseEnv(readFileSync("apps/server/.env.integ", "utf8")); Object.assign(process.env, integConfigs); ``` ### How often does it reproduce? Is there a required condition? It reproduces 100% of the time. The condition is that a variable must already exist in `process.env` (either from the shell or a previous `loadEnvFile` call) for the "bug" to be visible. ### What is the expected behavior? Why is that the expected behavior? While the default behavior of not overriding is standard for `dotenv`, there is currently no programmatic way (via options) to force an override using `process.loadEnvFile()`. At the very least, subsequent calls to `process.loadEnvFile()` should support an `{ override: true }` option to allow developers to switch environment contexts (e.g., switching to an integration/test config) without manually parsing files via `util.parseEnv`. ### What do you see instead? The variable remains locked to the first value it was assigned. Subsequent calls to `loadEnvFile` for the same key are silently ignored for that specific key. ### Additional information Most modern environment loaders (like the `dotenv` npm package) provide an `override` flag. Without this, `process.loadEnvFile` is significantly…