Prepare composite FK for vulnerability_occurrences

What does this MR do and why?

Following step 4 of the list partitioning guide, this adds a composite foreign key from vulnerability_occurrences to vulnerability_identifiers that includes the partitioning key, as part of preparing vulnerability_identifiers for list partitioning.

The new constraint is created as NOT VALID (validate: false); validation will follow in separate post-deployment migrations, matching the pattern used for vulnerability_occurrence_identifiers (fk_rails_be2e49e1d0_p). The existing single-column FK fk_rails_c8661a61eb is left in place and will be removed after the new constraint is validated.

Migration output

Up:

ALTER TABLE vulnerability_occurrences
    ADD CONSTRAINT fk_rails_c8661a61eb_p
    FOREIGN KEY (partition_id, primary_identifier_id)
    REFERENCES vulnerability_identifiers (partition_id, id)
    ON UPDATE CASCADE ON DELETE CASCADE NOT VALID;

Down:

ALTER TABLE vulnerability_occurrences DROP CONSTRAINT IF EXISTS fk_rails_c8661a61eb_p;

Both directions were verified locally (db:migrate:up / db:migrate:down), and db/structure.sql was regenerated with scripts/regenerate-schema.

References

• Related to #596858 (closed)

How to set up and validate locally

1. Run the migration and inspect the constraint:

   bundle exec rails db:migrate
   psql -d gitlabhq_development_sec -c '\d vulnerability_occurrences' | grep fk_rails_c8661a61eb_p

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.