Add limit to workflow link fields

What does this MR do and why?

Adds a call limit of one session per request to the six DuoWorkflow GraphQL link connections (workItemLinks, mergeRequestLinks, noteLinks, pipelineLinks, workflowLinks, and inverseWorkflowLinks). The limit is guarded by the default-off limit_duo_workflow_link_fields gitlab_com_derisk feature flag so it can be rolled out and rolled back independently.

Each connection resolves per session with no batching, so selecting them on a duoWorkflowWorkflows list multiplies query count by the page size. In-repo clients load one session by ID and are unaffected.

With the feature flag enabled, selecting a link field for more than one session, or repeating it through aliases, returns:

"noteLinks" field can be requested only for 1 DuoWorkflow(s) at a time.

References

• https://gitlab.com/gitlab-org/gitlab/-/work_items/635068
• FF rollout issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/635293

Screenshots or screen recordings

No UI changes.

How to set up and validate locally

1. Create two Duo Agent Platform sessions for your user, for example by running the Developer flow twice.

2. Enable the feature flag in the Rails console:

   Feature.enable(:limit_duo_workflow_link_fields)

3. In GraphiQL at /-/graphql-explorer, run a list query selecting a link field:

   query getWorkflowLinks {
     duoWorkflowWorkflows(first: 2) {
       nodes { id noteLinks { nodes { linkType } } }
     }
   }

   The response includes the field can be requested only for 1 DuoWorkflow(s) at a time error.

4. Run the query for one session to confirm that it resolves without errors.

5. Disable the feature flag:

   Feature.disable(:limit_duo_workflow_link_fields)

6. Note that the query in 3 can return links for multiple 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.