Let fine-grained tokens read the GitLab Duo settings GraphQL types

What does this MR do and why?

Without an authorize_granular_token directive, a fine-grained personal access token gets null for two types that GitLab Duo administrator mutations return. Each now declares, with parent_authorizes:, the permission its mutation already checks, and leaves authorization_todo.txt:

• AdminDuoAvailabilityLockedAncestor: lock_namespace_duo_feature. AdminSetDuoAvailability checks it on the group it changes, and returns this type as conflictingAncestor (the locked ancestor of that group) and affectedAdminLockedDescendants (its locked subgroups).
• CloudConnectorProbeResult: check_ai_self_hosted_model_connection. AiSelfHostedModelConnectionCheck checks it on the instance and returns this type as result.

gitlab:permissions:validate requires a mutation payload's type to rely on the mutation's own check, which both mutations have. The other fields that return these types belong to types still on the list, which keep denying the token. Both permissions exist, so there is no new permission. This is the GitLab Duo settings domain in one MR, as agreed in !267273 (comment 4195231927).

References

Closes #639739

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. As an administrator, run adminSetDuoAvailability with NEVER_ON on a top-level group, and create a fine-grained token with "Namespace Duo Feature: Lock" on one of its subgroups.

2. Run with that token:

   mutation {
     adminSetDuoAvailability(input: { groupId: "gid://gitlab/Group/<subgroup id>", availability: NEVER_ON }) {
       errors
       conflictingAncestor { fullPath }
     }
   }

3. On master conflictingAncestor is null; on this branch it is the top-level group, as in the administrator's session.

Checks I ran (Ruby 3.3.11)

I ran the steps above as the new examples of set_duo_availability_spec.rb and connection_check_spec.rb.

• On this branch, the two changed specs: 29 examples, 0 failures, 2 pending (skips of the shared example).
• With master's two type files, the same specs: 29 examples, 3 failures, the three new examples; and gitlab:permissions:validate lists both types as missing granular token authorization.
• gitlab:permissions:validate, RuboCop, the commit linter and Danger's linters pass; both compile_docs tasks leave the committed docs unchanged. Left to the pipeline: Ruby 3.4 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.