MCP migration blocks same-name servers in different workspace roots

- MCP migration rejects same-name servers across workspace roots, even though each server would move into its own root’s `.mcp.json` without overwriting the other.

### Steps to reproduce

1. Open a trusted multi-root workspace containing `root-a` and `root-b`.
2. Create `.vscode/mcp.json` in each root with identical contents:
```json
{
"servers": {
"same": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-everything"]
}
}
}
```
Leave both workspace-root `.mcp.json` files absent.
3. Set `chat.customizations.mcpServerMigration.enabled` to `true`, `chat.mcp.access` to `"all"`, and `chat.mcp.autostart` to `"never"`. Starting the servers is unnecessary.
4. Select an Agent Host / Copilot CLI session whose scope includes both roots.
5. Open **Chat: Open Customizations → Migrations → Migrate MCP Servers**, select an offered `same` entry, and confirm migration.

- **Expected:** Each entry can migrate to its own root’s `.mcp.json`. A matching name in another root should not, by itself, block independent file migration.
- **Actual, confirmed in code and existing tests:** Migration rejects the entry because another workspace root defines the same name and asks the user to rename or remove the duplicate.
- **Extensions disabled:** Not checked.

Details for investigation

- Found while investigating #335820. The refresh-loop fix in #335860 does not change this restriction.
- The [migration guard](https://github.com/microsoft/vscode/blob/658f8e95803a59b458bbd8ca0c11124564dbded5/src/vs/workbench/contrib/chat/browser/aiCustomization/mcpServerCustomizationMigration.ts#L253-L287) treats a matching name in another root’s source or destination as a conflict, regardless of whether the configurations are identical.
- There is a separate runtime consideration: [session MCP discovery](https://github.com/microsoft/vscode/blob/658f8e95803a59b458bbd8ca0c11124564dbded5/src/vs/platform/agentHost/node/shared/sessionMcpDiscovery.ts#L178-L190) merges roots by server name, with the first root winning. Per-root default working directories can also differ. Allowing migration must account for runtime precedence rather than silently changing which server is used.
- The cross-root rejection was verified from source and existing migration tests; the manual UI sequence above was not executed during this investigation.