Let fine-grained tokens read userPermissions on Duo and security types

What does this MR do and why?

DuoWorkflowPermissions, AiCatalogItemPermissions, VulnerabilityPermissions, GroupSecretsManagerPermissions and ProjectSecretsManagerPermissions have no authorize_granular_token directive, so fine-grained tokens are denied them. A token with read_vulnerability that selects userPermissions gets Cannot return null for non-nullable field Vulnerability.userPermissions and a null vulnerability.

Each is only reachable through userPermissions on parents that authorize the token:

Type	Parents
DuoWorkflowPermissions	DuoWorkflow (read_duo_workflow)
AiCatalogItemPermissions	The four AiCatalogItem types (read_ai_catalog_item)
VulnerabilityPermissions	Vulnerability, CountableVulnerability (read_vulnerability)
GroupSecretsManagerPermissions	GroupSecretsManager (read_secrets_manager)
ProjectSecretsManagerPermissions	ProjectSecretsManager (read_secrets_manager)

This MR gives them skip_reason: :parent_authorizes, removes them from authorization_todo.txt, and adds a skipped child type example per parent. !266824 (merged) did the same for six CE types.

The secrets manager specs called the missing directive by design, but !240596 (merged) listed these types as a workaround, its review expecting a token that reads the parent to read userPermissions too. I removed that comment.

With !266839 (merged) applied, gitlab:permissions:validate names none of the five types, so they need no parent_permissions:.

References

• Related to #593878, the GraphQL gaps for fine-grained tokens.
• !261877 (merged) gave AiCatalogItemConsumerPermissions the same skip.

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

Screenshots or screen recordings

Not applicable.

How to set up and validate locally

1. In a private project with a vulnerability, where you have the Developer role, create a fine-grained token with Vulnerability: Read.
2. Send { vulnerability(id: "<vulnerability global ID>") { userPermissions { readVulnerability } } } to /api/graphql with it.
3. On master vulnerability is null with the error above. On this branch it returns userPermissions.

I ran steps 2 and 3 as the new example in vulnerabilities/vulnerability_spec.rb, and the other parents in six more specs: userPermissions fails on master's code and returns on this branch.

Checks I ran (Ruby 3.3.11)

• On master's code, the new examples give 18 examples, 9 failures: each example whose token holds the parent's permission, all on userPermissions.
• On this branch, the seven request specs and the type specs of the three permission types that have one: 501 examples, 1 failure, 6 pending. The failure is a quarantined N+1 example in work_item_spec.rb that CI skips, and it fails the same on master's code.
• gitlab:permissions:validate passes and compile_docs changes nothing. RuboCop and the commit linter: no findings.
• With !266839 (merged) applied on today's master, the validation fails only on ProjectPermissions from !266824 (merged) (Project.userPermissions and ProjectMember.userPermissions), and the same with master's code for the five types.

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.