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 nêu việc khởi tạo môi trường startup và phân giải `${VAR}` trong cấu hình agent và MCP, nhưng không có tệp triển khai hoặc bài kiểm thử nào. Hãy bắt đầu bằng cách lần theo các điểm truy cập đó và cách cấu hình dự án cũng như cấu hình người dùng được phát hiện. Phần hoàn thành cần bao gồm hành vi ưu tiên `.env` được yêu cầu và một thiết kế hoặc triển khai rõ ràng cho phạm vi theo từng agent, với mức bao phủ cho cả hai phần.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.