Resolve tool aliases in the MCP list_tools allowed filter

What does this MR do and why?

API::Mcp::Handlers::ListTools#invoke filtered the tool list by comparing the names from X-Gitlab-Enabled-Mcp-Server-Tools against canonical tool names only. A header that carried an alias (for example list_all_merge_request_notes for get_merge_request_notes) was logged as an unknown tool and the tool was dropped from the response. This is the same bug class fixed on the producer side in !249839 (merged), but the consumer still breaks when any other caller sends alias names, and during a rolling deploy when a session built by a pre-rename node reaches a post-rename node.

This MR maps each allowed name through Mcp::Tools::Manager#resolve_alias before filtering, which is what get_tool already does for tools/call.

References

• Resolves #618876 (closed)
• Related: #606029 (closed)
• Related: !249839 (merged)

Differences

Before: tools/list with X-Gitlab-Enabled-Mcp-Server-Tools: list_all_merge_request_notes returns an empty tool list and logs "Unknown MCP tool names in allowed_tools".

After: The same request returns get_merge_request_notes, and nothing is logged as unknown.

How to set up and validate locally

1. Create an OAuth token with the mcp scope.

2. Send a tools/list request naming a tool by its alias:

   curl -s -X POST "http://gdk.test:3000/api/v4/mcp" \
     -H "Authorization: Bearer <token>" \
     -H "Content-Type: application/json" \
     -H "X-Gitlab-Enabled-Mcp-Server-Tools: list_all_merge_request_notes" \
     -d '{"jsonrpc":"2.0","method":"tools/list","id":"1"}'

3. On master the tools array is empty. With this MR it contains get_merge_request_notes.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.