Attribute the MR SAST report query to vulnerability management

What does this MR do and why?

• The getMrSastReport GraphQL query on the MR page enqueues a ReactiveCachingWorker job for Security::MergeRequestSecurityReportGenerationService, but that job inherits the page's code_review_workflow feature category instead of being attributed to Vulnerability Management, which owns the computation.
• This MR sets the query's Apollo context.featureCategory to vulnerability_management, matching the pattern already used by CI components on the same page (for example pipelines_table_wrapper.vue), and updates the query's @feature_category annotation to match.
• This is a metrics and logging attribution fix only. It does not change any request behaviour.
• This should be surfaced to the Vulnerability Management group, since it moves load onto their apdex.

Detailed context for AI agents

Root cause

GraphQL requests are categorised by GraphqlController#feature_category, which reads the x-gitlab-feature-category request header via Gitlab::FeatureCategories.default.from_request. When a query on an MR page doesn't set that header, it inherits the page's own category, code_review_workflow. That category becomes the meta.feature_category context for the request, which the enqueued ReactiveCachingWorker job for Security::MergeRequestSecurityReportGenerationService then inherits too (not_owned workers take the feature category of the request that enqueued them; see WorkerAttributes.get_feature_category).

A Kibana breakdown of ReactiveCachingWorker jobs with meta.feature_category = code_review_workflow over 24h in production showed 33,437 jobs (about 13% of that slice) from GraphqlController#execute:getMrSastReport with related_class: Security::MergeRequestSecurityReportGenerationService. Security::MergeRequestSecurityReportGenerationService specs and the FindingReportsComparer GraphQL type specs both already use feature_category: :vulnerability_management, so that is the correct owner.

Mechanism

• ee/app/assets/javascripts/rapid_diffs/merge_request_app.js: the getMrSastReport query call in #initSast now passes context: { featureCategory: 'vulnerability_management' }, with a one-line comment explaining why. Apollo's instrumentation_link.js (app/assets/javascripts/lib/apollo/instrumentation_link.js) turns that into the x-gitlab-feature-category request header.
• ee/app/assets/javascripts/rapid_diffs/graphql/get_mr_sast_report.query.graphql: the # @feature_category: annotation changes from code_review_workflow to vulnerability_management, so it matches the header. This annotation feeds the known GraphQL operations metadata used for GraphQL SLI labels (lib/gitlab/metrics/rails_slis.rb).
• ee/spec/frontend/rapid_diffs/merge_request_app_spec.js: the existing "fetches SAST findings when the report is available" example now also asserts the context passed to query.

Precedent

Eight CI components on MR pages already do this, for example app/assets/javascripts/ci/merge_requests/components/pipelines_table_wrapper.vue, which passes featureCategory: 'continuous_integration'.

Verification performed

• Jest: ee/spec/frontend/rapid_diffs/merge_request_app_spec.js, 8 passed.
• Prettier clean.
• ESLint clean on the JS files. The .graphql file reports a pre-existing local environment error about a missing schema dump (tmp/tests/graphql/gitlab_schema_apollo.graphql), which also occurs on master and is unrelated to this change.

Out of scope

• Nothing else on the page changes; no user-visible behaviour change.
• No changelog trailer: not user facing.

References

• Origin discussion: !254437 (comment 3861759678)
• Companion MR: !256703 (merged) (replaces the closed !256681 (closed))
• This MR: !256683 (merged)

Screenshots or screen recordings

No UI change.

How to set up and validate locally

1. Open an MR with a SAST report on an Ultimate project with the rapid diffs SAST findings feature enabled.
2. In the browser network tab, find the getMrSastReport GraphQL request and confirm the x-gitlab-feature-category request header is vulnerability_management.
3. Run the Jest spec: ee/spec/frontend/rapid_diffs/merge_request_app_spec.js.

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.