Values from .env are propagated to executed process

Vaultenv reads a `.env` file, if present, to get _it’s own_ configuration (e.g. `VAULT_HOST` or `VAULTENV_CONNECT_TLS`). However, it also makes everything set by the `.env` file available to the spawned process.

This happens because the environment includes `cLocalEnvVars`: https://github.com/channable/vaultenv/blob/285463d13c907d29f10fb8c900a5704a8d6878e3/app/Main.hs#L396

which is populated from among others the `.env` file: https://github.com/channable/vaultenv/blob/285463d13c907d29f10fb8c900a5704a8d6878e3/app/Main.hs#L265-L278

I’m not sure if this is intentional or not, but it did leave me confused for a bit, because Vaultenv complained

[ERROR] Found duplicate environment variable

for a variable (unrelated to Vaultenv) that I happened to define in my `.env`, and also wanted to set with a secret. For my use case, I _don’t_ want Vaultenv to pass what’s in `.env` along to the spawned process. (The `.env` happens to be there for local development, and I want to write a script that executes migrations in production, so it fetches the `PGUSER` and `PGPASS` for the production database.)

I’m not sure if this behavior is intentional. If it is, I would document it in the readme, and possibly add a way to disable it (though `--no-inherit-env` or `--inherit-env-blacklist` are fine for working around it).

Start with the linked locations in app/Main.hs around lines 265-278 and 396 to trace how .env values reach the spawned process. Review the README and the issue's proposed inheritance options, then establish the intended behavior with maintainers. Done means the chosen behavior is implemented or documented, with the reported duplicate-variable case addressed.

Written by the indexing model from the issue text.