Declare assignable_when conditions on CI granular token consumers

What does this MR do and why?

This MR is one of seven that split !253276 (merged) into pieces that each need only Authorization approval plus at most one other CODEOWNERS section. This one needs Authorization and Verify.

A consumer earns a condition tag only when it rejects every request from a caller who does not meet the condition, for every parameter. Partial checks, feature flags, and license checks do not count. The admin condition covers authenticated_as_admin! checks and admin-only global abilities. Nothing changes at request time. The only effect is that the token creation UI stops offering a permission at boundaries where the current user does not meet the condition.

This MR tags 9 consumers (28 tags) with the admin condition: 3 GraphQL runner mutations (create, delete, update) and 6 REST endpoints covering CI minutes, runner controllers, runner controller scopes and tokens, admin CI variables, and runner registration. 16 YAML files gain assignable_when: admin, covering ci_cd/ci_minute, ci_cd/runner, ci_cd/runner_controller and its token variants, ci_cd/runner_registration_token, and ci_cd/variable.

PUT/DELETE /runners/:id and POST /runners/:id/reset_authentication_token stay untagged. Their REST decorator declares a single assignable_when shared across all boundaries, and the admin check only holds at the instance boundary, not at group or project.

References

• Original MR being split: !253276 (merged)
• Parent MR that added GraphQL assignable_when support: !253246 (merged)
• MR that introduced assignable_when for REST endpoints: !246776 (merged)
• Sibling MRs from the same split:
  • !253276 (merged) (Declare admin assignable_when conditions on granular token consumers)
  • !255011 (merged) (Declare SaaS and self-managed assignable_when conditions)
  • !255014 (merged) (Declare assignable_when conditions on Geo granular token consumers)
  • !255015 (merged) (Declare assignable_when conditions on system hook consumers)
  • !255016 (merged) (Declare assignable_when conditions on the admin token API)
  • !255017 (merged) (Declare assignable_when conditions on the experiments API)

Screenshots or screen recordings

No UI changes in this MR.

How to set up and validate locally

1. Run bundle exec rake gitlab:permissions:validate. It passes.

2. Remove the assignable_when: block from config/authz/permission_groups/assignable_permissions/ci_cd/runner_controller/read.yml and run the task again. It fails and lists the consumer in ee/lib/api/ci/runner_controllers.rb with Consumer conditions: [admin]. Restore the block.

3. Enable the granular_personal_access_tokens feature flag, then query the GraphQL accessTokenPermissions field (or open the fine-grained token creation page) as a regular user and as an administrator, and compare the boundaries returned for read_runner_controller. The regular user does not get INSTANCE.

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.