fix: ignore default .env probe on permission denied

[ndeloof]

The default .env lookup is an implicit convenience, not something the user asked for. When the working directory denies even probing for it (EACCES on stat — e.g. sudo -u other-user with a 0700 home as cwd), warn and skip the default instead of failing the whole command.

Conservative scope: only os.IsPermission is softened, and only for the implicit default — any other stat failure stays fatal, and an explicit env file behind the same permission wall still errors in WithDotEnv.

Fixes docker/compose#14166

🤖 Generated with Claude Code

[thaJeztah]

I'm not 100% sure if this is correct though; running with a different user, then skipping .env could mean "now you're deploying to a different environment (e.g. production instead of test).

Given that there's already an escape hatch through the env-var, I'm not sure if we should do this.

[thaJeztah]

(and the correct mitigation would be to chmod the .env file if it must be used, or COMPOSE_DISABLE_ENV_FILE=1 if it's ok to ignore the .env file.

[glours]

LGTM

[ndeloof]

I'm not 100% sure if this is correct though; running with a different user, then skipping .env could mean "now you're deploying to a different environment (e.g. production instead of test).

This is also true if you run from the wrong folder, or any comparable situation where the target environment is set by .env and user unfortunately shoot into its own foot as compose loads a default .env file from PWD. Also consider compose looking for a compose.yaml file from parent folder(s). There are actually many ways to break a compose deployment if you're not careful, that's the price to pay for (too much?) flexibility introduced over time