Title: MCP tools with dots in names cause 400 Bad Request — should match MCP spec

When an MCP server returns tools with dots (.) in their names, Copilot CLI sends them to the API which rejects them with a 400 error:

✗ Execution failed: CAPIError: 400 tools.19.custom.name: String should match pattern
'^[a-zA-Z0-9_-]{1,128}$'

The MCP specification explicitly allows dots in tool names (section 5.1.1). VS Code Copilot handles this by remapping tool names internally (dots → underscores), but the CLI passes them through raw and the API rejects them.

Steps to Reproduce

1. Configure an MCP server that returns tools with dots in names (e.g., Backstage's @backstage/plugin-mcp-actions-backend v0.1.10+ which generates names like catalog.get-entity-facets)
2. Start Copilot CLI
3. Send any prompt → 400 Bad Request

Expected Behavior

API should accept dots per the MCP spec.

Actual Behavior

Hard failure — CLI becomes completely unusable when any MCP server has dotted tool names.

Environment

- Copilot CLI: latest
- OS: macOS / Windows / Linux (all affected)

Related Issues

- VS Code (warning, not error): https://github.com/microsoft/vscode/issues/308463
- IntelliJ (same hard failure): https://github.com/microsoft/copilot-intellij-feedback/issues/1583
- MCP spec discussion on tool name pattern: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1603
- MCP Spec — Tool Names: https://modelcontextprotocol.io/specification/2025-11-25/server/tools

Start by reproducing the failure with an MCP server returning a dotted tool name such as catalog.get-entity-facets, then trace the Copilot CLI path that sends MCP tools to the API. Done means dotted names no longer produce a 400 error while conforming to the MCP specification, with coverage for the affected request path.

Written by the indexing model from the issue text.