Create security_scan_profile_project_statuses table and model

What does this MR do and why?

Adds the security_scan_profile_project_statuses table and Security::ScanProfileProjectStatus model to persist profile-specific scan status per project per scan type.

The existing analyzer_project_statuses table tracks inventory-level status across all enablement methods and must not be modified. This new table stores profile-scoped status separately, enabling scanner health indicators for security profiles.

Closes #593131 (closed)

Implementation details

• Migration creates security_scan_profile_project_statuses on the gitlab_sec database with:
  • Unique index on [project_id, scan_type] (upsert target for future status update service)
  • Index on security_scan_profile_id (FK lookup)
  • Index on build_id (required for loose FK cleanup)
  • Direct FK to security_scan_profiles with cascade delete (same database)
  • Loose FKs for project_id (async_delete) and build_id (async_nullify) for cross-database references, matching the pattern used by analyzer_project_statuses
• Model inherits from SecApplicationRecord and provides three computed helpers:
  • stale? — true when status is not not_configured, last_scan_at is present, and older than 90 days
  • active? — true when success? and not stale
  • profile_failed? — true when failed? and consecutive_failure_count >= 3
• Associations added:
  • Security::ScanProfile — has_many :security_scan_profile_project_statuses
  • EE::Project — has_many :security_scan_profile_project_statuses
• Import/Export — registered security_scan_profile_project_statuses in all_models.yml (not exported, status is runtime data)

Cross-database considerations

Column	Target DB	Strategy
project_id	gitlab_main	Loose FK with async_delete
build_id	gitlab_ci	Loose FK with async_nullify (via CiPipelinesBuildsCleanupCronWorker)
security_scan_profile_id	gitlab_sec	Direct FK with on_delete: :cascade

MR acceptance checklist

• Tests added for model validations, enums, scopes, computed helpers, and loose FK cleanup
• Migration is safe (single create_table, no data migration, no locks on existing tables)
• Loose FK configuration validated (spec/lib/gitlab/database/loose_foreign_keys_spec.rb passes)
• All loose FK columns have indexes (build_id, project_id, security_scan_profile_id)
• Model registered in all_models.yml for Import/Export awareness
• No changes to existing analyzer_project_statuses or inventory behavior
• RuboCop passes on all changed files

Related

• Parent issue: #591555 (closed)
• Implementation plan: #591916 (closed)
• Blocked by: nothing
• Blocks: #593132 (closed), #593133 (closed)

Changelog: added
EE: true