refactor(cli): cover project-environment and local-project-context with effect lint (CLI-2650)

[7ttp]

TL;DR

brings the project .env loader and the local project context under the effect lint

whats introduced?

• project-environment, local-project-context, dotenv, vault and vault-decrypt join the allow list, and viper-env follows in the next PR of this stack
• the project .env files are read through the FileSystem and Path services and fail in the error channel, so both callers keep the same failed to read config: Error: ... text
• the read order, shell-wins precedence, a kept leading BOM and the missing, unreadable or directory .env cases behave as before, and a .env FIFO no longer blocks Ctrl+C
• SUPABASE_ENV and SUPABASE_PROJECT_ID are read through Config with the same empty and unset handling
• tests pin env through Config, stay hermetic against an exported SUPABASE_ENV or SUPABASE_PROJECT_ID, and cover the BOM, directory, symlink loop and .env.local skip cases

ref

• related: CLI-2650

[github-actions]

🤖 AI Review

Verified all four findings against the checked-out code and trusted conventions. Confirmed two minor quality concerns and one error-handling nit. Refuted the actionability finding because the trusted CLI convention requires those declarations on every new error class. No major or critical regression or fundamental next-branch conflict found. Tests were not executed.

Findings

Severity	Location	Category	Sources	Claim
🟡 MINOR	apps/cli/src/command-internal/local-project-context.ts:41	consistency	claude	Environment selection uses Config, while ambient values and their precedence still use process.env. An injected ConfigProvider can therefore select one dotenv environment while the merged ambient values reflect another source.
🟡 MINOR	apps/cli/src/command-internal/project-environment.ts:75	observability	codex	The converted multi-file dotenv workflow lacks its own named span despite the repository's tracing convention for filesystem workflows.
⚪ NIT	apps/cli/src/command-internal/project-environment.ts:83	error-handling	claude	Config read failures become defects in the project-environment and local-project-context paths, while the signing-keys caller converts the same SUPABASE_ENV read into a typed caller error.

Refuted findings (kept for transparency, not posted as review comments)

• apps/cli/src/command-internal/project-environment.ts:25 (dead-code): ProjectEnvironmentError's actionability declarations are unnecessary because both production callers replace it with their own errors; invalidConfig also potentially misclassifies filesystem read failures.
  Refuted: The wrapping behavior is accurately described, but removing the declarations would violate the trusted, documented error-classification convention, which has no exception for wrapped internal errors. The alleged filesystem misclassification is hypothetical: these callers discard the original declaration before command telemetry receives the error.

Stats

Claude findings: 3 · Codex findings: 1 · Confirmed: 3 · Refuted: 1 · Uncertain: 0

---

Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.