Plugin MCP servers cannot resolve the active project directory

### Describe the bug

An MCP server loaded from an installed plugin is launched with its working directory set to the plugin installation root, and the child process receives no project/workspace path. A project-scoped MCP server therefore reads and writes the plugin installation instead of the repository passed to Copilot CLI.

This is observable with Copilot CLI 1.0.73 on Linux when using either `--plugin-dir` or an installed plugin.

### Steps to reproduce

1. Create a plugin manifest that points at a plugin-root MCP config:

```json
{
"name": "cwd-probe",
"mcpServers": "./.mcp.json"
}
```

2. Use this `.mcp.json`:

```json
{
"mcpServers": {
"probe": {
"command": "sh",
"args": [
"-c",
"pwd > /tmp/plugin-mcp-pwd.txt; env > /tmp/plugin-mcp-env.txt; exec my-mcp-server"
]
}
}
}
```

3. Run the plugin against a different project:

```sh
copilot -C /tmp/example-project --plugin-dir /tmp/cwd-probe
```

4. Inspect the captured files.

### Actual behavior

- `PWD` is `/tmp/cwd-probe`, not `/tmp/example-project`.
- The MCP child receives `COPILOT_PLUGIN_ROOT` and `PLUGIN_ROOT`, but it does not receive `COPILOT_PROJECT_DIR` (plugin hooks do receive that variable).
- The MCP `initialize` request advertises only `sampling` and `elicitation`; it does not advertise MCP roots, so the server cannot request the workspace through `roots/list`.
- Setting `"cwd": "${workspaceFolder}"` leaves the value unresolved and fails before the child starts with `No such file or directory (os error 2)`.

The full initialization payload captured from 1.0.73 was:

```json
{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{"sampling":{},"elicitation":{"form":{},"url":{}}},"clientInfo":{"name":"github-copilot-developer","version":"1.0.73"}}}
```

### Expected behavior

A plugin-provided MCP server needs a supported way to resolve the active project. Any one of these would unblock project-scoped servers:

- launch plugin MCP children from the active project directory;
- pass `COPILOT_PROJECT_DIR` to MCP children as Copilot already does for plugin hooks; or
- expose a documented project variable / MCP roots capability that plugin MCP configuration can pass to the server.

The plugin root should remain available separately through `COPILOT_PLUGIN_ROOT`.

### Impact

Project-scoped MCP tools can silently operate on files inside the cached plugin installation. In [archcore-ai/plugin#24](https://github.com/archcore-ai/plugin/issues/24), the MCP tools register and return success, but document writes land under the installed plugin rather than the project, which prevents a safe Copilot plugin release.

Reproduce the issue with `copilot -C /tmp/example-project --plugin-dir /tmp/cwd-probe` and trace the plugin MCP launch path, working-directory selection, environment construction, and initialization capabilities. Done means a plugin MCP server can resolve the active project without losing the separate plugin root, using one of the supported approaches described in the issue.

Written by the indexing model from the issue text.