Add auto resolve profile and triggers

What does this MR do and why?

Introduces the auto_resolve security scan profile type and selects Security::ScanProfiles::Configuration JSON schemas per trigger type and scan type, instead of only per scan type.

auto_resolve sits alongside the existing dependency_scanning_post_processing type rather than replacing it; migrating the post-processing profile onto auto_resolve is planned separately.

Profile type	Triggers
dependency_scanning_post_processing	sbom_ingested (unchanged)
auto_resolve (new)	sbom_ingested, sast_false_positive, sast_vulnerability_resolution, secret_detection_false_positive, vulnerability_enrichment

ScanProfiles::Configuration::SCHEMAS now uses nested structure: a String value is one schema for every trigger of that scan type, and a Hash represents a schema per trigger, used only for auto_resolve.

Trigger (on auto_resolve)	Schema
sbom_ingested	existing post-processing schema (shared with dependency_scanning_post_processing)
sast_false_positive	security_profile_sast_false_positive_configuration.json
sast_vulnerability_resolution	security_profile_sast_vulnerability_resolution_configuration.json
secret_detection_false_positive	security_profile_secret_detection_false_positive_configuration.json
vulnerability_enrichment	security_profile_vulnerability_enrichment_configuration.json

Configuration#trigger_type is a virtual attribute, not a column: the trigger owns the persisted value, and the foreign key points from trigger to configuration, so a configuration built before its trigger exists can't read it. Both scan profile services now pass trigger_type explicitly when building a configuration to allow the validation based on the trigger type.

Configuration.defaults_for takes (scan_type, trigger_type = nil), and DEFAULTS follows the same String/Hash shape as SCHEMAS.

Existing behaviour for sast, secret_detection, dependency_scanning and dependency_scanning_post_processing profiles (validation, defaults, Duo override) is unchanged.

Not included

No GraphQL exposure. SecurityScanProfileType does not publish AUTO_RESOLVE and ScanProfileTriggerType does not publish the four new trigger types, so auto_resolve profiles cannot be created or read through the API yet.

Changelog: added
EE: true

Related issue

[Backend] Wire configuration to new auto-resolv... (#619372 - closed) • Gal Katz • 19.4

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.