Add toolset infrastructure and tag all MCP tools

What does this MR do and why?

Adds toolset infrastructure to MCP tools and tags every registered tool with its toolset declaration. Each tool now declares a toolset via register_version metadata or route_setting, a new Mcp::Tools::Toolsets module owns the three category constants (ALWAYS_ON, DEFAULT, OPT_IN), and Manager gains a tools_in_toolsets helper. A coverage spec fails CI if any tool is missing a valid toolset declaration, and a separate spec enforces that aggregated routes never declare a toolset (the toolset belongs on the aggregator tool, not its constituent routes).

This is the foundation for toolset-based filtering in tools/list, which lands in the follow-up MR.

Toolset assignments

Toolset	Category	Tools
meta	Always on	1
core	Default	9
merge_requests	Default	10
work_items	Default	9
repository	Default	10
ci	Default	6
duo_agent_platform	Opt-in	2
wikis	Opt-in	1
code_security	Opt-in	3

Tools missing a toolset: declaration fall back to :unassigned at runtime (visible but not filterable). CI catches these — the coverage spec asserts every tool is reachable through a declared toolset.

Naming decisions

• duo_agent_platform (not agent_platform): aligns with the product name "Duo Agent Platform" so MCP clients see a name that matches GitLab's public terminology.
• get_work_item_types placed in work_items (not core): it operates on work item type metadata so it belongs with the other work item tools.

Full tool-to-toolset mapping (51 tools)

Tool	Toolset
accept_merge_request	merge_requests
add_branch	repository
add_commit	repository
attach_scan_profile	code_security
create_issue	work_items
fork_repository	repository
get_commit	repository
get_duo_session	duo_agent_platform
get_issue	work_items
get_job	ci
get_mcp_server_version	meta
get_merge_request	merge_requests
get_merge_request_commits	merge_requests
get_merge_request_conflicts	merge_requests
get_merge_request_diffs	merge_requests
get_merge_request_notes	merge_requests
get_merge_request_pipelines	merge_requests
get_pipeline	ci
get_pipeline_jobs	ci
get_project	core
get_repository_file	repository
get_saved_view_work_items	work_items
get_user	core
get_vulnerability	code_security
get_work_item	work_items
get_work_item_types	work_items
get_workitem_notes	work_items
link_work_items	work_items
list_branches	repository
list_commits	repository
list_duo_sessions	duo_agent_platform
list_groups	core
list_merge_requests	merge_requests
list_pipelines	ci
list_project_members	core
list_projects	core
list_releases	repository
list_repository_tree	repository
list_tags	repository
list_vulnerabilities	code_security
list_wiki_pages	wikis
list_work_items	work_items
manage_pipeline	ci
save_merge_request	merge_requests
save_merge_request_review	merge_requests
save_note	core
save_pipeline	ci
save_work_item	work_items
search	core
search_labels	core
semantic_search	core

References

• #607755 (closed)
• Part 1 of 2 for #607755 (closed)

Screenshots or screen recordings

No UI changes.

How to set up and validate locally

1. Run the manager specs:

   bundle exec rspec spec/services/mcp/tools/manager_spec.rb

2. Run the toolset coverage spec:

   bundle exec rspec spec/services/mcp/tools/toolset_coverage_spec.rb

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.