Let fine-grained tokens read job needs, stage groups and runner managers

What does this MR do and why?

A fine-grained personal access token that can read a pipeline gets, with no error, no job groups in its stages, no needs for its jobs, and no runner manager for a job or a runner. The three types below declare no authorize_granular_token directive, and such a token is denied every type without one.

Each is returned only by fields of a type that already authorizes the token, so each declares the permission its data needs with parent_authorizes:, the form added by !266839 (merged), and leaves authorization_todo.txt:

Type	Returned only by	Declared permission
CiGroup	CiStage.groups	read_pipeline_stage
CiBuildNeed	CiJob.needs, CiJob.previousStageJobsOrNeeds	read_job
CiRunnerManager	CiJob.runnerManager, CiRunner.managers	read_runner

read_pipeline_stage and read_job are not project policy abilities, and previousStageJobsOrNeeds returns a union that also holds CiJob, so CiStage.groups, CiJob.needs and CiJob.previousStageJobsOrNeeds check the permission in a directive of their own, as gitlab:permissions:validate asks, and doc/auth/tokens/fine_grained_access_tokens_graphql.md lists the three fields. CiJob.runnerManager and CiRunner.managers check read_runner on the boundary of their parent.

CiRunnerManager keeps its user check, read_runner_manager.

PipelineMessage (Pipeline.errorMessages and Pipeline.warningMessages), which the first version of this MR also covered, is no longer part of it and stays on authorization_todo.txt.

A question for Authorization: CiJob.runnerManager now needs Runner: Read, as CiJob.runner does. REST returns a runner manager with read_job on GET /projects/:id/jobs/:job_id and with read_runner on GET /runners/:id/managers. Is that right for the job path? Every field that returns the type checks the one permission it declares, and read_job can only be granted on a project, so following read_job there would take a separate runner manager type.

References

• Related to #593878, the remaining 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. As a Maintainer of a private project with a pipeline whose job uses needs and ran on a project runner, create a fine-grained token with Project: Read, Pipeline: Read, Job: Read and Runner: Read.

2. Run with it:

   query { project(fullPath: "<path>") { pipeline(iid: "<iid>") {
     stages { nodes { groups { nodes { name } } } }
     jobs { nodes { needs { nodes { name } } runnerManager { systemId } } } } } }

3. On master groups and needs return nodes: [null] and runnerManager is null; on this branch they return data. Without Runner: Read, runnerManager stays null.

I ran steps 2 and 3 as a local request spec: with the token of step 1, the query gets the nodes: [null] and null of step 3 on master's code, with no error, and the data on this branch. Each field has new examples in pipelines_spec.rb, jobs_spec.rb and runner_spec.rb.

Checks I ran (Ruby 3.3.11)

• With master's types, todo list and generated page, the three changed spec files: 213 examples, 5 failures, 5 pending; the five failures are the new examples that expect the data, each getting nil.
• With the previous version of this branch, where the three types declare no permission, gitlab:permissions:validate fails and names the three types, and the new example for a token without Runner: Read fails, since that version returns the runner manager.
• On this branch, those files with the stages, groups and project jobs request specs and the type specs of the types and their parents: 308 examples, 0 failures, 7 pending (shared example skips for a namespace without a top-level group, as on master).
• bundle exec rake gitlab:permissions:validate passes. gitlab:permissions:graphql:compile_docs wrote the three field rows of fine_grained_access_tokens_graphql.md; run again, it and gitlab:permissions:routes:compile_docs leave the documentation unchanged.
• RuboCop on the eight Ruby files: no offenses. The commit linter and Danger's commit and title linters: no findings.
• Left to the pipeline: Ruby 3.4.10 and the FOSS jobs.

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.