Backport of 'Strip the trusted flag from client-supplied MCP tools in Workhorse' to 19.4

What does this MR do and why?

Backport of !257045 (merged) to 19-4-stable-ee. It is a clean cherry-pick of 7e93af0a.

Workhorse marks the MCP tools from the servers that Rails sends as trusted. On 19.4, Workhorse also forwards the MCP tools of the IDE client with the trusted value that the client sets. This MR clears trusted on client tools before Workhorse adds the Rails server tools.

Why this is necessary on 19.4: when "Allow external MCP tools" is off, the Duo Workflow Service keeps trusted Orbit tools. It does this only for GitLab versions where Workhorse clears client trust, which today means 19.5.0 and later. On 19.3 and 19.4, the agent gets no Orbit tools unless the root group turns on external MCP tools. Dedicated runs 19.3.x now. After this backport ships, gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!7469 (merged) lowers the floor to the patch versions that have this change.

How to set up and validate locally

1. In workhorse/, copy config.toml.example to config.toml and point [redis] URL at a running Redis.
2. Run go test ./internal/ai_assist/duoworkflow/... -count=1. The package passes.
3. Remove the four new lines from runner.go and run the test again. start request strips trusted from client mcp tools fails.

References

• Default branch MR: !257045 (merged)
• Duo Workflow Service floor change: gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!7469 (merged)
• gitlab-org/orbit/knowledge-graph#1036 (closed)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
• The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
• The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
• Required labels have been applied to this merge request
  • severity label and bug subtype labels (if applicable)
  • If this MR fixes a bug that affects customers, the customer label has been applied.
• This MR has been approved by a maintainer (only one approval is required).
• Ensure the E2E Omnibus GitLab EE pipeline (triggered by thee2e:test-on-omnibus-ee job) has succeeded. If it has failed (or shows warnings), investigate the failures. If you determine the failures are unrelated, you may proceed. If you need assistance investigating, request help in the #s_developer_experience Slack channel to confirm the failures are unrelated to the merge request.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

• Refer to the patch release runbook for engineers and maintainers for guidance.
• Ask questions on the #releases Slack channel (internal only).
• Once the backport has been merged, the commit changes will be automatically deployed to a release environment that can be used for manual validation. See after merging runbook for details.