Add optional dotenvx support in Next.js for encrypted env management (Native support)

[harshsoni-harsh]

Goals

1. Raise the security bar – enable file-level and per-variable encryption of .env secrets (AES-256 + ECIES) so a leaked file is useless without the private key.
2. Offer multi-environment workflows (-f) that let developers compose .env.dev, .env.staging, etc., without juggling files manually.

Non-Goals

1. Replace @next/env as the default loader (keep current behaviour for most users).
2. Change the existing NEXT_PUBLIC_* client-side injection rule.
3. Introduce a mandatory new dependency - dotenvx should be opt-in and disabled by default.

Background

Next.js today loads .env* files through @next/env, but it lacks:
Encryption – secrets are stored in plaintext; a stray commit or log can expose credentials.
Flexible env switching – developers end up renaming files or scripting around the limitation.
dotenvx tackles these pain points:
Per-variable encryption with a project-wide public key; private key is only needed at runtime, not in the repo.
dotenvx run -f .env.prod -- next dev style workflows for layered merges.
A rich CLI (encrypt, rotate, get, set, etc.) and IDE helpers that decrypt on-the-fly.

Proposal

Opt-in flag in next.config.js, e.g.
module.exports = {
experimental: { useDotenvx: true }
}
At startup, call dotenvx.config() (fallback to dotenv in next-env when disabled).
Ship concise docs: “Enable encrypted envs with npx dotenvx encrypt -> commit the encrypted file and public key, keep the private key in your secret store.

[tianhuil]

I would be in favor of this. Currently, getting these 2 technologies to work is pretty jenky (see dotenvx/dotenvx#616 (comment)). Avoiding these issues would be really helpful.