Add ai_workflows scope to vulnerability dependency GraphQL fields

What does this MR do and why?

GraphQL field scopes default to [:api, :read_api] (app/graphql/types/base_field.rb). The dependency field on VulnerabilityLocationDependencyScanning, VulnerabilityLocationContainerScanning, and VulnerabilityLocationClusterImageScanning had no ai_workflows scope, and neither did the fields on VulnerableDependency/VulnerablePackage. So ai_workflows-scoped OAuth tokens (Duo Agent Platform) got silent null for dependency data, no GraphQL errors, since the fields are nullable. The sibling file/blobPath fields already had the scope, so this looks like a missed spot in an earlier scoping pass.

This also fixes an existing silent bug: the AI Gateway list_vulnerabilities tool already selects dependency { package { name } version } and has been getting null all along for DAP tokens.

Related to #614544 (closed). Companion AI Gateway MR: gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!6538 (merged). Either merge order is safe.

Changes

• scopes: [:api, :read_api, :ai_workflows] added to the three dependency fields.
• VulnerableDependency and VulnerablePackage get the authorization_scopes override plus field scopes. Both halves are needed since the type-level check runs unconditionally.
• operating_system on the cluster-image-scanning type also gains the scope. It was the one field on that type left unscoped, silently nulling for ai_workflows tokens, same bug class.
• The grant is deliberately type-wide (covers VulnerablePackage#path and the cluster-image-scanning dependency field with no current gateway consumer), because the types are shared and package name/version/path is no more sensitive than what list_vulnerabilities already exposes.
• Type specs extended for field scopes and authorization_scopes on all five types, plus two request specs in ee/spec/requests/api/graphql/vulnerabilities/location_spec.rb that post with a real ai_workflows OAuth token and assert dependency.package.name and dependency.version resolve. Both were proven to fail with the scope grant removed.

How to set up and validate locally

1. Check out this branch in gitlab/ and run gdk restart rails-web.

2. Pick a project that has a dependency-scanning vulnerability (any project where the vulnerability report shows one).

3. Create an OAuth token restricted to the ai_workflows scope, in a Rails console:

   app = Doorkeeper::Application.create!(name: 'ai-workflows-test', redirect_uri: 'https://example.com', scopes: 'ai_workflows')
   token = Doorkeeper::AccessToken.create!(application: app, resource_owner_id: User.find_by(username: 'root').id, scopes: 'ai_workflows')
   token.plaintext_token

4. Query the vulnerability location with that token:

   curl -s "http://gdk.test:3000/api/graphql" \
     -H "Authorization: Bearer <plaintext_token>" \
     -H "Content-Type: application/json" \
     -d '{"query": "{ project(fullPath: \"<group>/<project>\") { vulnerabilities(reportType: [DEPENDENCY_SCANNING]) { nodes { location { ... on VulnerabilityLocationDependencyScanning { dependency { version package { name } } } } } } } }"}'

5. Before this MR: dependency is null with no errors key. After: it returns the version and package name.

6. Repeat with an api-scoped token (a normal PAT works): the result is the same before and after, this MR only widens who can read the fields.