[Bug] Bun Windows - Stale process.env values from transpilation cache

### What version of Bun is running? 1.4.0-canary.1+5b98630ac ### What platform is your computer? Microsoft Windows NT 10.0.19044.0 x64 ### What steps can reproduce the bug? 1. Create a single file `index.ts`: ```ts console.log("HOST:", process.env.DATABASE_HOST); ``` 2. Create `.env`: ```env DATABASE_HOST="value-A" ``` 3. Run it (establishes transpilation cache): ``` $ bun index.ts HOST: value-A ``` 4. Change `.env` **without modifying any `.ts` file**: ```env DATABASE_HOST="value-B" ``` 5. Run again: ``` $ bun index.ts HOST: value-A ``` The output is **still `value-A`** even though `.env` says `value-B`. 6. Even deleting `.env` entirely and running again **still prints `value-A`**, proving the value comes from a cached transpilation, not from the filesystem. 7. The only fix: modify any byte of `index.ts` (add a comment, then remove it), which forces re-transpilation and picks up the new `.env` value. ### What is the expected behavior? Each `bun index.ts` invocation starts a fresh process, reads `.env` from disk, and all `process.env.*` accesses happen at runtime. Changing `.env` should take effect on the next run. ### What do you see instead? `process.env.*` values are permanently baked into a transpilation cache keyed by **source file content hash**. Changing `.env` does not invalidate the cache. The application silently uses stale values with no warning or error. Evidence table: | Step | `.env` value | Source file changed? | Output | |------|-------------|---------------------|--------| | 1 | `value-A` | No (original) | `value-A` (establishes cache) | | 2 | `value-B` | No | `value-A` (stale from cache) | | 3 | `.env` deleted entirely | No | `value-A` (proves cache, not `.env`) | | 4 | `value-C` | Yes (added a comment) | `value-C` (cache invalidated) | | 5 | `value-A` | Reverted to original | `value-A` (old cache hit again) | ### Additional information - **Windows-specific** - the same files under Docker Linux (`oven/bun:canary-slim`) correctly pick up new `.env` values every run. - The transpilation cache lives in `%TEMP%\bun-*`. Deleting these directories clears the stale cache (but affects all Bun projects). - **Workaround**: touch every `.ts` file that reads `process.env` after any `.env` change to force re-transpilation. - Any `process.env` access is affected; `import { SQL } from 'bun'` in the original project was coincidental. **Why this is HIGH severity:** - **Silent correctness failure** - no error, crash, or log; the application just uses wrong config. - **Security risk** - rotating compromised credentials in `.env` has no effect; the old keys remain in the cache. - **Operational risk** - changing `DATABASE_HOST` from a dead server to a live one is silently ignored. - **Undetectable** - `console.log(process.env.X)` and env inspection show current OS values, not the stale values Bun actually uses. - **Contagious** - source content hash as cache key means identical files across projects or machines share the same stale cache entry.