Let fine-grained tokens read component usage

What does this MR do and why?

A fine-grained personal access token that can read a project gets null for its componentUsages, because CiCatalogResourceComponentUsage declares no authorize_granular_token directive.

• ProjectUsageResolver now asks a new permission, read_ci_component_usage, on the project, bundled in an assignable permission of the same name (CI Component Usage: Read). A component usage is recorded when a pipeline includes a CI/CD catalog component, so it gets a permission of its own.
• CiCatalogResourceComponentUsage is returned only by componentUsages, so it declares parent_authorizes: :read_ci_component_usage, the form added by !266839 (merged), and leaves authorization_todo.txt.

The resolver's own checks for the user stay as they are. #639431 proposes checking the same permission for the user.

The pipeline subscription types (CiProjectSubscription, CiSubscriptionsProject and the project and namespace details of a subscription) stay on authorization_todo.txt: pipeline subscriptions have no read permission a token can be granted, only create and delete.

References

• Part of #638946, the Pipeline Authoring GraphQL types for fine-grained tokens.
• Related to #593878, the GraphQL gaps for fine-grained tokens.

I found this while working on gitlab-mcp-server.

Screenshots or screen recordings

No UI change.

How to set up and validate locally

1. On GitLab.com, in a project of a group you maintain whose pipelines include a CI/CD catalog component, create a fine-grained token with Project: Read and CI Component Usage: Read for the project, and run query { project(fullPath: "<project>") { componentUsages { nodes { name version } } } }.
2. On master the node is null; on this branch it returns the component. With Project: Read alone, componentUsages is null.

I ran this as new examples of project_component_usages_spec.rb, with the feature available as on GitLab.com.

Checks I ran (Ruby 3.3.11)

• The new examples use the shared examples for a field that asks a permission, for the type that skips, and for a token that holds only the parent's permission.
• With master's resolver, type and todo list, the granular token context gives 9 examples, 2 failures: a token with both permissions gets a null node, and one with Project: Read alone gets a list (with a null node) where it should get null.
• Putting back master's type and todo list alone fails only the example that reads the type. Putting back master's resolver alone fails none, because the type's parent_authorizes: :read_ci_component_usage then asks the same permission on the project.
• On this branch, that spec in full, the resolver and type specs, and the pipeline subscription specs: 65 examples, 0 failures, 2 pending (the shared examples' case for a public project, and one as on master).
• A walk of the loaded schema finds Project.componentUsages as the only field returning the type.
• gitlab:permissions:validate, RuboCop and the commit linter pass; gitlab:permissions:graphql:compile_docs adds Project.componentUsages under a new CI Component Usage section of fine_grained_access_tokens_graphql.md, and gitlab:permissions:routes:compile_docs changes nothing. Left to the pipeline: Ruby 3.4.10 and the rest of the suite.

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.