BE: Add support for atomic scanner rule criteria

Summary

Add backend support for atomic scanner rule criteria in Merge Request Approval Policies (MRAP), allowing different vulnerability filtering criteria to be specified per scanner type.

Background

Based on the discussion in #556415 (closed), we need to update the YAML schema and backend evaluation logic to support scanner-specific criteria in MRAP policies. This will enable users to configure different vulnerability attributes (KEV, EPSS, fix_available, false_positive) for each scanner type (Container Scanning, Dependency Scanning, SAST, etc.).

YAML Schema Changes

The current YAML structure applies filtering options globally to all security findings. The updated schema needs to support scanner-specific configurations:

rules:
- type: scan_finding
  branch_type: protected
  vulnerability_states: []
  scanners:
  - type: container_scanning
    vulnerability_attributes:
      fix_available: true
      false_positive: true
      epss_score:
        operator: greater_than
        value: 0.75
      kev: false
  - type: dependency_scanning
    vulnerability_attributes:
      fix_available: false
      false_positive: true
      epss_score:
        operator: greater_than
        value: 0.15
      kev: true

Backend Implementation Requirements

1. YAML Schema Update: Modify the schema to support nested vulnerability_attributes within each scanner type
2. Policy Evaluation Logic: Update approval evaluation to:
   • Consolidate attributes per scanner type
   • Execute separate queries when attributes differ between scanners
   • Maintain backward compatibility with existing policy configurations

Considerations

1. Backward Compatibility: Determine how to render existing configurations in the updated editor:

   • Show separate rules for each selected scanner (may duplicate some settings)
   • OR maintain old view when legacy YAML config is detected

2. Migration Path: Define strategy for transitioning existing policies to the new schema

Related Issues

• Parent Epic: #16311 (closed) - Add filter option for KEV in MR approval policies
• Related: #556415 (closed) - UX designs and discussion for scanner-specific criteria

Implementation Notes

Reference spike implementation: !214982 (closed)

For kev attribute, consider using a single-line boolean format similar to other vulnerability attributes (fix_available, false_positive), potentially named known_vulnerability or kev_value.

/cc @imam_h @sashi_kumar @arfedoro @aturinske