Authorize 5 Secrets Manager GraphQL types for fine-grained tokens

Summary

A fine-grained personal access token is denied the Secrets Manager GraphQL types below: they declare no authorize_granular_token directive and are still listed in config/authz/graphql/authorization_todo.txt, so the queries that list a group's or a project's secrets permissions, and the one that reads a namespace's enrollment, give the token an empty list or null, even when it can read the secrets manager. A legacy token can use them.

GroupSecretsManagerPermissions and ProjectSecretsManagerPermissions already skip the token check because their parent checks it, but are listed in the same file because they do not declare that permission yet.

As agreed in !267273 (comment 4195231927), I will send this domain's types in one merge request, which closes this issue.

The other three Secrets Manager types on the list, GroupSecret, ProjectSecret and SecretRotationInfo, stay there: no assignable permission grants read_secret yet, so none fits them, and they need a permission decision by the Authorization team.

Proposal

• authorize_granular_token with the existing read_secrets_manager, which the GroupSecretsManager and ProjectSecretsManager types already check: GroupSecretsPermission on its group, ProjectSecretsPermission and SecretPermission on their project, and SecretsManagerEnrollment on its namespace.
• Principal, returned only below a secrets permission, declares the permission its parent checks (parent_authorizes: :read_secrets_manager), with a spec for each parent.
• GroupSecretsManagerPermissions and ProjectSecretsManagerPermissions declare parent_authorizes: :read_secrets_manager, the permission of the secrets manager that returns them.

I expect no new permission.

Related to #593878.

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