Let fine-grained tokens read the Secrets Manager GraphQL types

What does this MR do and why?

Without an authorize_granular_token directive, a fine-grained personal access token gets no data from five Secrets Manager types: the secrets permissions of a group or project come back as an empty list, and a namespace's enrollment as null. Each now declares one and leaves authorization_todo.txt:

• GroupSecretsPermission, ProjectSecretsPermission and SecretPermission take read_secrets_permission on the group or project of the permission, from a new Read assignable permission next to Update and Delete (secrets_permission/read.yml, groups and projects). A token that reads the secrets manager does not list who holds which actions.
• Principal, returned only below those three types, declares parent_authorizes: :read_secrets_permission, so the project policy enables read_secrets_permission with read_project_secrets_manager, the ability that lists a project's permissions.
• SecretsManagerEnrollment takes read_secrets_manager on its namespace, which GroupSecretsManager already checks.
• GroupSecretsManagerPermissions and ProjectSecretsManagerPermissions already skipped with parent_authorizes and now name their parent's permission, read_secrets_manager, so their lines leave the list too. They are the follow-up agreed in !269587 (comment 4202991029).

The types and resolvers keep their user checks. The secrets permission and enrollment mutations keep their own token check, and return the record to a token that can also read it.

This is the Secrets Manager domain in one MR, as agreed in !267273 (comment 4195231927).

GroupSecret, ProjectSecret and SecretRotationInfo stay listed: no assignable permission grants read_secret yet, so none fits them; they need a permission decision by the Authorization team.

References

Closes #639821

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 group with Secrets Manager enabled, as an Owner, create a fine-grained token for it with Secrets Permission: Read, and run:

   query {
     groupSecretsPermissions(groupPath: "<group>") { nodes { actions principal { id type } } }
   }

2. On master nodes is empty; on this branch it lists the Owner role's permission.

3. Remove Secrets Permission: Read from the token: nodes is empty again.

I ran these steps as the new examples of the group list spec.

Checks I ran (Ruby 3.3.11)

I saw the new examples fail first: with master's seven type files and project policy in place of this branch's, bundle exec rspec on the changed specs gave 68 examples, 13 failures, 3 pending (the five type checks, the legacy token denial of the four queries, the skipped child example of the three lists, and the enrollment's granted token), the policy examples below gave 40 examples, 40 failures, and bundle exec rake gitlab:permissions:validate reported the new assignable permission as unused.

On this branch:

• bundle exec rspec on the changed specs and on the specs of the permission and enrollment mutations and of the two userPermissions queries: 239 examples, 0 failures, 8 pending.
• bundle exec rspec ee/spec/policies/project_policy_spec.rb -e read_secrets_permission -e 'allows the read permissions except the excluded ones': 40 examples, 0 failures. bundle exec rspec ee/spec/lib/authz/role_definitions_spec.rb: 78 examples, 0 failures.
• bundle exec rake gitlab:permissions:graphql:compile_docs gitlab:permissions:routes:compile_docs gitlab:permissions:validate: valid, and no file changed.
• bundle exec rubocop on the 19 changed Ruby files: no offenses.
• scripts/lint/commit_linter.rb and Danger's commit and MR title linters: no problems.

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.