feat(mcp): add tool_name_prefix to disambiguate duplicate MCP tool names

[adityasingh2400]

When two MCP servers expose tools with the same name (e.g. both a GitHub and a Linear server expose create_issue), wiring both into an agent fails with Duplicate tool names found across MCP servers. The existing include_server_in_tool_names agent-level flag auto-generates a server-derived prefix, but users have no way to pick a short, friendly prefix per server – the original ask in the issue.

This PR adds an optional keyword-only tool_name_prefix argument to the MCPServer base class and the MCPServerStdio, MCPServerSse, and MCPServerStreamableHttp constructors. When set, list_tools() returns tools named f"{prefix}_{original_name}" and call_tool() strips the prefix before dispatching to the upstream MCP server, so the server still receives its original tool name. The internal cache and tool_filter continue to operate on the upstream names, and require_approval policy lookups continue to match the original tool name even with a prefix configured. A prefixed name that would exceed the 64-character MCP tool-name limit raises UserError early at list_tools() time rather than failing later.

Tests cover the two-servers-with-different-prefixes case, prefix stripping on call_tool() (both via the FakeMCPServer and an end-to-end check against the real MCPServerStdio with the MCP client patched), composition with tool_filter, the 64-char overflow error, and cache invariants. Docs in docs/mcp.md get a short new section showing how to use it. Closes #464.

[adityasingh2400]

Note on the duplicate label. PRs #2677 and #2788 both went stale before landing rather than being rejected on substance. The closest prior attempt, #2788, hit a concrete blocker that seratch flagged in his review, the auto-derived prefix from a non-ASCII server label produced invalid OpenAI tool names.

This PR takes a different shape on that exact point. The prefix is user-provided as a keyword argument on the MCPServer constructor, not derived from the server label, so the non-ASCII generation path does not exist here. The user picks the short readable prefix per server ("github", "linear") and the SDK leaves it alone aside from length validation against the 64-char tool-name ceiling. The internal cache, tool_filter, and require_approval lookups continue to operate on the upstream tool name, and call_tool strips the prefix before dispatch so the server still receives its original name.

Happy to rebase or split the docs section out if that helps land the core API change.