Let fine-grained tokens read the Source Code GraphQL types

What does this MR do and why?

Without an authorize_granular_token directive, a fine-grained token gets no data from 11 Source Code types and cannot run BranchRuleSquashOptionCreate. Each now declares one and leaves authorization_todo.txt:

• The three commit signature types take read_commit_signature and CommitReferences read_commit_ref, as the commit signature and refs endpoints do. PathLock takes read_code, which read_path_locks follows.
• ForkDetails takes read_code on the upstream, and its resolver on the fork, as the field checks the user: the change !267275 (merged) left for later.
• BranchRuleSquashOptionCreate takes create_squash_option on the branch rule's project, as the update mutation does. This adds create_squash_option to the existing create_branch_rule, as update_branch_rule and delete_branch_rule hold the other two.
• The types returned only below those take their parent's permission with parent_authorizes:. SquashOption skips without one until the branch rule type has a directive.

It also declares the parent permission of Blame, RepositoryCodeownerValidation and AccessLevelDeployKey, as offered in !269587 (comment 4204222716) (details below). Key stays on the list: as a TodoableInterface type, a parent permission on it would differ from the other types Todo.target returns.

This is the Source Code domain in one MR, as @alexbuijs agreed in !267273 (comment 4195231927). Most of its 447 lines are specs, one for every parent of each type; the code is 29 lines.

Each type, its parents and its directive

Types	Returned by	Directive
GpgSignature, SshSignature, X509Signature	Commit.signature	read_commit_signature, project
X509Certificate, X509Issuer	X509Signature.x509Certificate, X509Certificate.x509Issuer	parent_authorizes: :read_commit_signature
CommitReferences	Project.commitReferences	read_commit_ref, project
CommitParentNames	the four tipping and containing fields of CommitReferences	parent_authorizes: :read_commit_ref
PathLock	Project.pathLocks	read_code, project
PathLockPermissions	PathLock.userPermissions	parent_authorizes: :read_code
ForkDetails	Project.forkDetails, ProjectSyncFork	read_code, the upstream; the resolver on the fork
SquashOption	the squash option mutations, BranchRule.squashOption	skip_reason: :parent_authorizes
BranchRuleSquashOptionCreate (mutation)		create_squash_option, the branch rule's project

The three types that already skipped with parent_authorizes:

• Blame takes read_repository_blob, what RepositoryBlob checks. REST blame asks read_repository_file_blame; both are in Repository: Read, so I followed the parent, as TreeEntry does.
• RepositoryCodeownerValidation takes read_code, what Repository checks.
• AccessLevelDeployKey takes read_deploy_key, the only permission the directive of Project.availableDeployKeys accepts. No field checks it at runtime yet, so no token changes. read_deploy_key is not a project or group policy ability, so PushAccessLevel.deployKey will need its own directive once its type has one.

References

Closes #639817

Related to #593878

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

Screenshots or screen recordings

No UI change.

How to set up and validate locally

1. In a private project with a GPG-signed commit and a path lock, run as a Maintainer with a token that reads Project, Code, Repository and Commit:

   query {
     project(fullPath: "<project>") {
       repository { tree(ref: "<signed commit>") { lastCommit { signature { commitSha } } } }
       pathLocks { nodes { path } }
     }
   }

2. On master the path locks are empty and signature is null; on this branch they return data.

Checks I ran (Ruby 3.3.11)

I ran the steps above as examples of the changed request specs.

• With master's types, resolver, model and todo list, the changed specs give 202 examples, 28 failures. With master's create_branch_rule as well, the squash option create spec does not load, as no assignable permission holds create_squash_option.
• On this branch, the changed specs and those of blame, the CODEOWNERS validation and the deploy keys: 228 examples, 0 failures.
• gitlab:permissions:validate, RuboCop, Keela, the commit linter and Danger's linters pass; both compile_docs tasks leave the committed docs unchanged. Left to the pipeline: Ruby 3.4.10 and the FOSS run.

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.