Backfill dismissed status in vulnerability flags

What does this MR do and why?

Adds a batched background migration to backfill vulnerability_flags records that were not covered by the prior detected-status backfill migration (from milestone 18.9).

The prior migration (BackfillDetectedStatusInVulnerabilityFlags) only handled flags with confidence_score > 0, setting detected_as_fp or detected_as_not_fp based on the confidence threshold. This left two categories of flags with status = not_started:

1. Manually dismissed flags (origin LIKE 'manual_%', confidence_score = 0) - these are set to dismissed
2. AI detection flags with zero confidence (origin IN ('ai_sast_fp_detection', 'ai_secret_detection_fp_detection'), confidence_score = 0) - these are set to failed

This migration is a prerequisite for enabling the vulnerability_flag_status_based_gating feature flag (!226166 (merged)), which moves all gating logic from confidence-score-based to status-based.

References

• Parent issue: https://gitlab.com/gitlab-org/gitlab/-/issues/591057
• Feature flag rollout issue: #595697
• Related MR (model/service refactoring): !226166 (merged)
• Prior backfill migration: !223468 (merged)

How to set up and validate locally

1. Run the migration:

   bin/rails db:migrate

2. Verify in Rails console:

   # Check manually dismissed flags were backfilled
   Vulnerabilities::Flag.where("origin LIKE 'manual_%'").where(status: :not_started).count
   # => Should be 0
   
   # Check AI flags with zero score were backfilled
   Vulnerabilities::Flag.where(origin: 'ai_sast_fp_detection', confidence_score: 0, status: :not_started).count
   # => Should be 0

3. Run the migration spec:

   bundle exec rspec ee/spec/lib/ee/gitlab/background_migration/backfill_dismissed_status_in_vulnerability_flags_spec.rb

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.

• This MR adds a batched background migration with specs
• Migration is idempotent (safe to run multiple times)
• Migration only touches rows with status = 0 (not_started)