Feature: Support .env file loading and per-agent environment variable scoping

## Summary

Copilot CLI should support automatic `.env` file loading from the project root, and allow agents to declare environment variables scoped to their configuration — so that different agents can have isolated secrets without polluting the global shell environment.

## Problem

When building custom agents with Copilot CLI that use MCP servers requiring credentials (e.g., the Slack MCP server needing `SLACK_USER_OAUTH_TOKEN`), all credentials must be exported in `~/.bashrc` or equivalent shell profile because:

1. Copilot CLI does not load `.env` files from the project directory
2. Agent `env:` blocks in MCP config use `${VAR}` syntax, which resolves from the shell environment only
3. There is no way to scope environment variables per-agent

### No project-scoped configuration
Secrets for one project leak into every shell session. A `.env` file at the repo root (gitignored) is the standard pattern for project-scoped secrets in every major framework (Node.js, Python, Ruby, Go). Copilot CLI is the only tool in my workflow that forces secrets into the global shell profile.

### No secret isolation between agents
If you have multiple agents, each needing different MCP servers, every agent currently sees every exported variable in the shell. Per-agent env scoping would follow the principle of least privilege — an agent that only needs a Slack token should not have access to other API keys.

### Onboarding friction
When sharing a multi-agent repo, contributors need to manually add exports to their shell profile. A `.env.example` + `.env` pattern is universally understood and self-documenting.

## Proposed Solution

### Part 1: `.env` file loading (minimum viable)
- On startup, if a `.env` file exists in the project root (or git root), load it into the environment before resolving `${VAR}` references in agent/MCP configs
- Respect `.env` files at both user level (`~/.copilot/.env`) and project level (`.env` in git root), with project-level taking precedence

### Part 2: Per-agent environment scoping (stretch goal)
Allow agents to declare their own env vars or reference a specific `.env` file:

```yaml
---
name: slack-agent
env:
SLACK_USER_OAUTH_TOKEN: ${SLACK_USER_OAUTH_TOKEN}
env_file: .env.slack
---
```

This would restrict which variables are available to that agent's MCP server subprocesses.

## Current Workaround

Export all variables in `~/.bashrc` and maintain a `.env.example` in the repo for documentation only:

```bash
# ~/.bashrc
export SLACK_USER_OAUTH_TOKEN=xoxp-...
```

This works but violates standard project-scoping conventions.

## Related Issues

- #1232 — `${}` env var expansion in MCP config (implemented, but only reads from shell env)
- #1354 — Per-agent model selection (similar theme of per-agent configuration)

Payload では、agent と MCP の設定における startup 環境の初期化と `${VAR}` の解決が示されていますが、実装ファイルやテストはありません。まず、これらのエントリーポイントと、プロジェクト設定およびユーザー設定がどのように検出されるかを追跡してください。完了条件には、要求された `.env` の優先順位の動作と、agent ごとのスコープに関する明確な設計または実装を含め、両方の部分をカバーする必要があります。

索引モデルが issue の本文から書いたものです。