Let fine-grained tokens read nine Code Review GraphQL types

What does this MR do and why?

A fine-grained personal access token gets null or an error from nine Code Review GraphQL types that declare no authorize_granular_token directive. On master, the non-null Discussion.userPermissions, WikiPage.userPermissions and DiffPosition.diffRefs null their discussion, wiki page or note position for such a token.

Five hold data of the object that returns them, so each declares that object's permission with parent_authorizes: and leaves authorization_todo.txt:

• read_merge_request: MergeRequestMergeabilityCheck.
• read_note: DiffLine, DiscussionPermissions, DiffRefs.
• read_wiki: WikiPagePermissions.

DiffRefs takes read_note because DiffPosition, which relies on it, also returns it, so MergeRequest.diffRefs now needs read_note too (follow-up: #639877).

Saved replies and target branch rules have a read check of their own for the user, so the token now checks read_saved_reply (new) and read_target_branch_rule (now defined). SavedReply, ProjectSavedReply, GroupSavedReply and ProjectTargetBranchRule declare it on their own boundary: the user, the project, or each reply's group, since a group also lists its ancestors' replies. Their mutations return the record when the token can also read it. The checks for the user do not change.

This is the Code Review domain's merge request, agreed in !267273 (comment 4195231927). The other five are in !267287 (merged) (BlockingMergeRequests, MergeRequestDiff, SuggestedReviewersType) and !269007 (merged) (ProjectSetting, DuoContextExclusionSettings).

References

Closes #638945

• 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. Create a fine-grained token with Project: Read, Merge Request: Read and Work Item: Read for a private project with a merge request that has a diff note.
2. Run query { project(fullPath: "<project>") { mergeRequest(iid: "<iid>") { diffRefs { headSha } discussions { nodes { userPermissions { resolveNote } } } } } } with it.
3. On master diffRefs and each discussion are null, with an error; on this branch both return data.

I ran these steps as the new request spec examples: those that expect data fail on master, and all pass on this branch.

Checks I ran (Ruby 3.3.11)

• The skipped child type shared example for each parent field: MergeRequest.mergeabilityChecks, MergeRequest.diffRefs, DiffPosition.diffRefs, Discussion.truncatedDiffLines, Discussion.userPermissions and WikiPage.userPermissions; and the parent-only example for MergeRequest.diffRefs.
• For the saved reply and target branch rule types, on savedReplies and savedReply of the current user, a project and a group, and on Project.targetBranchRules: a token with only the parent's read permission gets no data, and one with both gets the data; and the token permissions example on one field of each type. On Group.savedReplies(includeAncestorGroups: true) for a subgroup, a token for the parent group gets both groups' replies, one for the subgroup only the subgroup's. One example for each of the ten mutation payloads.
• With master's types and todo list, the new examples give 62 examples, 24 failures, 7 pending: exactly the examples that expect the data.
• With the types of the first review version, the 15 spec files the review commit changes give 153 examples, 10 failures, 23 pending: the examples where the token has only the parent's permission, and the group mutations without read_group.
• On this branch, the 17 changed spec files: 233 examples, 0 failures, 31 pending.
• gitlab:permissions:validate, RuboCop and the commit linter pass; gitlab:permissions:graphql:compile_docs adds the read rows of the four types to fine_grained_access_tokens_graphql.md, and with it the three compile_docs tasks change nothing. 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.