Support GitLab flows and project URLs in start_duo_session

What does this MR do and why?

The start_duo_session MCP tool shipped in !254979 (merged). This MR builds on it and adds the parts of the work item it did not cover.

That tool can only run a flow from the AI Catalog, named by its item consumer ID. The work item also asks for a GitLab flow by reference, a catalog flow by item ID, and a project named by URL.

The REST route behind the tool already accepts all of it:

• workflow_definition for a GitLab flow reference
• ai_catalog_item_version_id for a catalog version
• project_id as either an ID or a path

So the tool only maps its own arguments onto those, and the route keeps doing the authorization, tier and feature-flag checks.

New parameters:

Parameter	Notes
flow	GitLab flow reference. Defaults to developer/v1 when no flow is named.
flow_item_id	AI Catalog item ID. Resolved to the item's latest released version, because the route wants a version ID.
url	Project URL, reduced to the project path.

Only one flow may be named, and exactly one of url or project_id. ai_catalog_item_consumer_id keeps working as before, so nothing that calls the tool today changes.

Guard rails on those parameters:

• A GitLab flow's catalog item ID passed as flow_item_id is refused, naming the flow value to use instead, so a GitLab flow cannot skip the beta, tier and feature-flag gating that flow gets.
• The catalog path sets workflow_definition to ai_catalog_agent. Without it the column default applies and a catalog session is recorded as software_development in the flow metric and the credit metadata.
• A group URL, or a URL naming no project, is refused rather than passed on as a project path for the route to report as a missing project.
• An unknown catalog item and an item with no released version give different errors.

Also fixed

get_duo_session named two tools that are registered nowhere: trigger_duo_flow and ask_duo_agent. This MR drops both from its description and from its input schema, and names start_duo_session instead. The approval guidance is no longer changed here. Master already points callers to send_duo_session_input for plan_approval_required and tool_call_approval_required, so the rebase kept master's version.

The route's own an endpoint with mcp route setting example asserted the previous ROUTE_PARAMS list, so it is updated for the two new route parameters.

References

• Work item: #607619 (closed)
• The MR that added the tool: !254979 (merged)

Screenshots or screen recordings

No UI changes.

How to set up and validate locally

1. Restart rails: gdk restart rails-web

2. Create a personal access token with api and mcp scopes.

3. Start a GitLab flow by reference:

   curl -k -X POST "$GDK_URL/api/v4/mcp" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"start_duo_session","arguments":{"url":"http://gdk.test:3000/group/project","goal":"Add tests for the parser","flow":"developer/v1"}}}'

4. Run the specs: bundle exec rspec ee/spec/services/mcp/tools/duo_workflows/

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.