GraphQL API: Pagination fieldName should support aliases for multiple search queries

Problem

The dotCMS GraphQL API's pagination object does not support aliases, which creates ambiguity when performing multiple search queries in a single GraphQL request. Currently, when executing multiple search operations (e.g., searching for different content types), all pagination objects have the same fieldName value, making it impossible to determine which pagination data corresponds to which search query.

Current Behavior

When performing multiple searches like:

query ContentAPI {
  test: search(query: "+parentPath:/", limit: 10) {
    inode
  }
  blog: search(query: "+contentType:Blog", limit: 10) {
    title
  }
  destination: DestinationCollection {
    title
  }
  pagination: Pagination {
    page
    pageSize
    totalRecords
    fieldName
  }
}

The response contains multiple pagination objects with identical fieldName values:

{
  "data": {
    "test": [ ],
    "blog": [ ],
    "destination": [ ],
    "pagination": [
      {
        "page": 1,
        "pageSize": 10,
        "totalRecords": 364,
        "fieldName": "search"
      },
      {
        "page": 1,
        "pageSize": 10,
        "totalRecords": 6,
        "fieldName": "search"
      },
      {
        "page": 1,
        "pageSize": 100,
        "totalRecords": 5,
        "fieldName": "DestinationCollection"
      }
    ]
  }
}

Expected Behavior

The pagination fieldName should respect GraphQL aliases and return unique identifiers that correspond to each aliased search query, allowing developers to properly associate pagination data with their respective search results.

For example, if we alias our searches as test, blog, and destination, the pagination objects should have fieldName values of "test", "blog", and "destination" respectively, instead of all having "search" or "DestinationCollection".

The GraphQL resolver for pagination should dynamically assign fieldName based on the query alias if one is used, otherwise fall back to the default field name (search, DestinationCollection, etc.).

Impact

This limitation significantly affects:

• Complex queries that need to search multiple content types simultaneously
• Frontend applications that rely on pagination metadata to implement proper pagination UI
• API consumers who need to efficiently batch multiple search operations

Suggested Solution

Modify the GraphQL pagination resolver to:

1. Detect when a search query uses an alias
2. Use the alias name as the fieldName in the corresponding pagination object
3. Maintain backward compatibility for queries without aliases

Additional Context

This issue affects the ContentAPI's search functionality and impacts developers building applications that require multiple simultaneous searches with proper pagination handling.

Start by locating the ContentAPI GraphQL pagination resolver and the search resolver that produces pagination objects. Trace how fieldName is currently assigned for aliased and unaliased queries. Done means aliased searches report their aliases as fieldName, unaliased fields retain their existing names, and the behavior is covered by the relevant GraphQL tests.