Agent profiles and namespacing for user-level custom agents

### Describe the feature or problem you'd like to solve

User-level Copilot custom agents in ~/.copilot/agents/ have two compounding issues at scale:

1. **No namespacing.** The .agent.md filename is the agent's identity and the key for dedupe across the documented scope chain (system > repository > organization). When multiple teams independently publish an agent named, e.g., code-reviewer.agent.md, installing more than one into ~/.copilot/agents/ causes overwrites on disk. There is no way to distinguish "Team A's code-reviewer" from "Team B's code-reviewer."

2. **No user-level scoping.** Every agent in ~/.copilot/agents/ is available in every copilot session regardless of the current repo or task. /agents and --agent name space become long and noisy, and subagent routing has more candidates to disambiguate than necessary. There is no per-session or per-context filter that scales beyond manually curating the directory.

### Proposed solution

1. **Namespacing.** Add a namespace (or publisher) field to the agent YAML frontmatter, producing qualified identifiers like teamA/code-reviewer. The namespace participates in identity, dedupe, invocation (copilot --agent teamA/code-reviewer), and display. Unqualified names still work for back-compat but emit a warning on collision.

2. **Agent profiles.** Named profiles (e.g., work-backend, personal) that specify which user-level agents are active. The active profile could be selected via slash command (/profile work-backend), CLI flag (copilot --profile work-backend), config.json under COPILOT_HOME, and optionally auto-selected based on CWD or repo. Only agents in the active profile appear in /agents, resolve via --agent, or participate in subagent routing. All installed agents remain on disk.
Namespacing fixes identity; profiles fix relevance. Together they give organizations a practical path at scale.

### Alternatives considered

1. Rename-on-install (e.g., teamA-code-reviewer.agent.md) — works today but is ad-hoc, breaks author-intended names, and has no tooling support.
2. Per-repo installs in .github/agents/ — requires copying into every repo and doesn't fit agents that are genuinely user-scoped.
3. Org-level agents — helpful for canonical agents but doesn't address intentional diversity across teams or personal use.

### Example prompts or workflows

### Additional context

Related FR issue for VSCode GitHub Copilot: https://github.com/microsoft/vscode/issues/311920