Paginate the get_work_item notes facet in both directions

Tian Gaorequested to merge
622710-get-work-item-notes-pagination into master

What does this MR do and why?

Adds cursor pagination in both directions to the notes facet of the get_work_item MCP tool. Callers can now page forward with notes_first / notes_after, or backward with notes_last / notes_before (for reading the newest notes first), each capped at 100 items per page. The facet response now returns a full pageInfo object (hasNextPage, hasPreviousPage, startCursor, endCursor).

This also rewrites the facet description, which previously told agents to "use get_workitem_notes for full note pagination." That self-referral kept agents on the standalone tool and blocked its retirement.

Closes #622710 (closed) (GA must-have). This removes the capability gap blocking deprecation of the standalone get_workitem_notes tool; the deprecation itself is a separate follow-up.

Documentation updates:

  • doc/user/model_context_protocol/mcp_server_tools.md gains the four new parameter rows and a history entry.
  • doc/development/duo_agent_platform/mcp/_index.md's facet-pagination guideline now names the <facet>_first/<facet>_after (plus <facet>_last/<facet>_before where reading from the end matters) pattern, citing get_merge_request (forward-only) and get_work_item (bidirectional) as worked examples.

Design notes

  1. Backward pagination is included because the standalone tool paginates both directions and "newest notes first" is a common agent read; forward-only parity would not have been enough to retire it.
  2. When no pagination parameter is given, the facet keeps its previous behavior (first 100 notes), so existing callers see no change.
  3. Mixing directions (notes_first/notes_after with notes_last/notes_before) fails fast with a self-correcting validation error instead of surfacing the raw GraphQL connection error.
  4. The EE query override (ee/app/graphql/queries/mcp/work_items/get_work_item.query.graphql) mirrors the CE file because load_graphql resolves the EE file on EE instances — editing only the CE query silently changes nothing on EE.

How to validate locally

  1. Check out this branch and restart GDK's rails processes.
  2. Create a personal access token with api and mcp scopes.
  3. Call tools/call on get_work_item for a work item with 3 notes:
    • Default (no pagination params): returns all three notes.
    • notes_first: 1: returns the first note with hasNextPage: true.
    • Add notes_after set to the returned endCursor: returns the second note.
    • notes_last: 1: returns the newest note.
    • Combine both directions (notes_first/notes_after and notes_last/notes_before): returns the validation error.

The following is the transcript of an end-to-end run against GDK exercising the sequence above:

1. schema has notes params: true
2. default (all 3):  isError=false bodies=["n1", "n2", "n3"] pageInfo={"hasNextPage"=>false, "hasPreviousPage"=>false}
3. notes_first 1:    bodies=["n1"] hasNext=true
4. after cursor:     isError=false bodies=["n2"] pageInfo={"hasNextPage"=>true, "hasPreviousPage"=>true}
5. notes_last 1:     isError=false bodies=["n3"] pageInfo={"hasNextPage"=>false, "hasPreviousPage"=>true}
6. both directions:  isError=true "Validation error: Provide notes_first/notes_after or notes_last/notes_before, not both directions"

Merge request reports