Authorize fine-grained PATs for four GraphQL types

What does this MR do and why?

Four GraphQL types return null to fine-grained personal access tokens (granular PATs) even when the token holds the right read scopes. The same data is accessible through the REST API. The affected types are DiffStats and DiffStatsSummary (merge request and commit diff line counts), LinkedWorkItemType (linked items on a work item), and WorkItemType (work item type metadata like name and icon).

The root cause: a GraphQL type with no authorize_granular_token directive is denied outright for a granular token, even when it was reached through a parent type that already authorized the request. Legacy read_api tokens are not affected. These four types were grandfathered in config/authz/graphql/authorization_todo.txt, which only silences the validator, it does not grant access.

All four types are only reachable through a parent that enforces its own granular permission (a merge request via read_merge_request, a commit via read_code, a work item via read_work_item, a project or group via read_project or read_group). This MR adds authorize_granular_token skip_reason: :parent_authorizes to each type, recording in code that the parent already authorizes. The class-level authorize policy checks are unchanged. The four lines were removed from authorization_todo.txt. Running bundle exec rake gitlab:permissions:graphql:compile_docs produces no change because skipped types are not listed in the fine-grained token docs.

WorkItemType

The issue suggested authorize_granular_token permissions: :read_work_item_type, boundary: :project. This MR uses skip_reason instead. read_work_item_type is not a registered granular permission yet, it only exists as a line in config/authz/permissions/definitions_todo.txt, so the permissions form fails bundle exec rake gitlab:permissions:validate. WorkItemType is only reached through Project, Group, Namespace, or WorkItem, all of which authorize, so parent_authorizes fits and keeps the change minimal. Open to switching to a dedicated permission if a reviewer prefers.

This follows the same shape as three earlier merged fixes:

• #603527
• #606143
• #604498 (closed)

References

Resolves #626742

How to set up and validate locally

1. Create a fine-grained personal access token with these permissions across your memberships: Merge request Read, Work item Read, Code Read, Project Read.
2. Run GraphQL queries for merge request diffStats and diffStatsSummary, workItem.workItemType, and the linked items widget on a work item.
3. On master these fields come back null. With this change they return data, matching what the same token gets from the REST endpoints.

Automated coverage:

• spec/requests/api/graphql/merge_requests/diff_stats_spec.rb (new)
• spec/requests/api/graphql/project/work_item_types_spec.rb
• spec/requests/api/graphql/work_item_spec.rb

These use the authorizing granular token permissions for GraphQL shared examples, or the equivalent explicit examples for the linked items widget, which is reached through a path that also goes through a separate unauthorized wrapper type.

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.