Security: Regression — dotenv.config() calls still present in route modules despite #147 being closed

[LucasMaupin]

Summary

Issue #147 («Remove `dotenv`») was closed as resolved via PR #254, but `dotenv.config()` calls remain in two route modules:

• `src/api_productions.ts` lines 2 and 29 — imports and calls `dotenv.config()`
• `src/api_ingests.ts` lines 12 and 15 — imports and calls `dotenv.config()`

These redundant calls:

• Are order-dependent on the current working directory (the `.env` file must be in the CWD when the file is first `require`d)
• Conflict with the canonical `src/config/load-env.ts` (which already handles `.env` and `.env.local` loading)
• Silently fail in production Docker builds where no `.env` file is present, potentially masking missing environment variable errors
• Create a maintenance hazard: any future developer adding env-var reads to these modules may rely on a `dotenv.config()` call that only works locally

Reproduction

grep -rn "dotenv" src/api_productions.ts src/api_ingests.ts

Recommendation

1. Remove the `import dotenv from 'dotenv'` and `dotenv.config()` calls from `api_productions.ts` and `api_ingests.ts`
2. Ensure `src/config/load-env.ts` is imported at the top of `src/server.ts` (before any other module that reads env vars) — this is the single, canonical place for env loading
3. Add a lint rule or comment to `load-env.ts` so future contributors know not to add more `dotenv.config()` calls in route modules

References

• Closes regression introduced after Remove dotenv #147
• Related: Security: Add startup warnings for missing PUBLIC_HOST and DB_CONNECTION_STRING environment variables #268 (startup validation for env vars)