Return import, access level and upload data to fine-grained tokens

What does this MR do and why?

A fine-grained token that can read a project gets null for detailedImportStatus, three *AccessLevel fields and the upload of the upload mutations, because these three types declare no authorize_granular_token directive. Each is returned only below a parent that authorizes the token, so each now skips its own check and leaves authorization_todo.txt:

Type	Returned by	Token check
ProjectFeatureAccess	the three Project access level fields	read_project
DetailedImportStatus	Project.detailedImportStatus	read_project; read_project_import (new) on url and lastError
FileUpload	UploadCreate and UploadDelete payloads	create_markdown_upload, delete_markdown_upload

ProjectFeatureAccess and DetailedImportStatus declare parent_authorizes: :read_project, the form added by !266839 (merged). FileUpload declares parent_authorizes: :read_markdown_upload, which the REST routes that read uploads take, for a field that returns it outside the two mutation payloads.

GET /projects/:id gives the same import status and access levels under read_project, and POST /projects/:id/uploads the new upload under create_markdown_upload. DetailedImportStatus.url checks read_project_import for the user, and GET /projects/:id/import returns the import error under read_project_import, so url and lastError now ask the token for it too: Project: Read alone returns the status without the URL or the error.

ForkDetails stays on authorization_todo.txt as on master: its counts compare a fork with its upstream, and I'll give that a change of its own.

References

• Part of #638957, the Organizations GraphQL types for fine-grained tokens.
• Related to #593878, the GraphQL gaps for fine-grained tokens.
• !266059 (merged) put read_deploy_key on DeployKeyResolver the same way.

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 project you own whose import failed, give a fine-grained token Project: Read and run query { project(fullPath: "<project>") { detailedImportStatus { status url lastError } issuesAccessLevel { stringValue } } }.
2. On master detailedImportStatus and issuesAccessLevel are null. On this branch they return data, with url and lastError null; add Import: Read to the token and they return the URL and the error too.

I ran these steps and the two payloads as new examples of three request specs: the fields are null on master's code and return data on this branch.

Checks I ran (Ruby 3.3.11)

• The new examples are in project_query_spec.rb and mutations/uploads/create_spec.rb and delete_spec.rb. The two payloads have their own examples because the skipped child type shared example expects no GraphQL error when the token lacks the parent's permission, and a refused mutation returns one.
• With master's code (the three types and the todo list), the new examples give 20 examples, 12 failures: every example that expects data fails.
• Without the read_project_import directive of url or of lastError, only the example that denies that field to Project: Read alone fails.
• On this branch, the three changed request specs, the fork details and sync fork request specs as on master, and the four type specs: 126 examples, 0 failures, 5 pending. The five pending examples are pending on master too.
• gitlab:permissions:validate, RuboCop and the commit linter pass; gitlab:permissions:graphql:compile_docs adds only an Import section with DetailedImportStatus.lastError and url. Left to the pipeline: Ruby 3.4.10 and the rest of the suite.
• With skip_reason: :parent_authorizes on ProjectFeatureAccess and DetailedImportStatus, gitlab:permissions:validate fails and asks both to declare their permission. read_markdown_upload is assignable for projects and groups and is a GroupPolicy ability, but not a ProjectPolicy one, so a Project field that returns FileUpload would need its own directive with it.

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.