chore(migrations): renumber vuln-id migrations after rebase onto dev

dev added 0285_cicd_infrastructure, which collided with the vuln-id 0285.
Renumber the three vuln-id migrations to chain linearly after it:
  0285_vulnerability_id_entity_tables     -> 0286 (dep: 0285_cicd_infrastructure)
  0286_backfill_vulnerability_id_entities -> 0287
  0287_delete_vulnerability_id            -> 0288
makemigrations --check clean; single leaf (0288).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: Maffooch

…s/0285_vulnerability_id_entity_tables.py …s/0286_vulnerability_id_entity_tables.pydojo/db_migrations/0285_vulnerability_id_entity_tables.py renamed to dojo/db_migrations/0286_vulnerability_id_entity_tables.py dojo/db_migrations/0285_vulnerability_id_entity_tables.py renamed to dojo/db_migrations/0286_vulnerability_id_entity_tables.py

@@ -1,12 +1,12 @@
 # Vulnerability ID entity tables: the normalized Vulnerability registry and the ordered
 # Finding -> Vulnerability reference table. Both tables are CREATED EMPTY here, so every index
 # (including the two GIN indexes) is built on zero rows — the DDL is effectively instant and needs
-# no AddIndexConcurrently. The data backfill runs separately in 0286 (atomic=False, resumable).
+# no AddIndexConcurrently. The data backfill runs separately in 0287 (atomic=False, resumable).
 #
-# >50M-row fallback (documented, NOT the default path): on installs where the subsequent 0286
+# >50M-row fallback (documented, NOT the default path): on installs where the subsequent 0287
 # backfill would insert tens of millions of reference rows, GIN maintenance during the backfill
 # dominates. Such installs can strip the two GinIndex entries from the Vulnerability Meta here,
-# let 0286 populate the tables, then add both GIN indexes with CREATE INDEX CONCURRENTLY in a
+# let 0287 populate the tables, then add both GIN indexes with CREATE INDEX CONCURRENTLY in a
 # follow-up migration. Not needed for typical installs.
 
 import django.contrib.postgres.indexes
@@ -20,7 +20,7 @@
 class Migration(migrations.Migration):
 
     dependencies = [
-        ("dojo", "0284_backfill_finding_cwe"),
+        ("dojo", "0285_cicd_infrastructure"),
     ]
 
     operations = [

…86_backfill_vulnerability_id_entities.py …87_backfill_vulnerability_id_entities.pydojo/db_migrations/0286_backfill_vulnerability_id_entities.py renamed to dojo/db_migrations/0287_backfill_vulnerability_id_entities.py dojo/db_migrations/0286_backfill_vulnerability_id_entities.py renamed to dojo/db_migrations/0287_backfill_vulnerability_id_entities.py

@@ -1,5 +1,5 @@
 # Data-only backfill of the Vulnerability entity + FindingVulnerabilityReference tables created
-# in 0285. atomic=False so each set-based statement (and each finding_id window in the reference
+# in 0286. atomic=False so each set-based statement (and each finding_id window in the reference
 # build) commits on its own — a crash mid-backfill resumes where it left off, and ON CONFLICT DO
 # NOTHING everywhere makes any re-run a no-op on completed work. Insert-only into the two NEW
 # tables: dojo_vulnerability_id and dojo_finding are never rewritten, locked, or deleted, so
@@ -23,7 +23,7 @@ def backfill_vulnerability_id_entities(apps, schema_editor):
             connection.vendor,
         )
         return
-    from dojo.vulnerability.backfill import run_backfill  # noqa: PLC0415 -- keep entity import lazy/out of migration graph build
+    from dojo.vulnerability.backfill import run_backfill  # noqa: PLC0415 -- lazy import
 
     run_backfill(logger=logger)
 
@@ -35,7 +35,7 @@ class Migration(migrations.Migration):
     atomic = False
 
     dependencies = [
-        ("dojo", "0285_vulnerability_id_entity_tables"),
+        ("dojo", "0286_vulnerability_id_entity_tables"),
     ]
 
     operations = [

…grations/0287_delete_vulnerability_id.py …grations/0288_delete_vulnerability_id.pydojo/db_migrations/0287_delete_vulnerability_id.py renamed to dojo/db_migrations/0288_delete_vulnerability_id.py dojo/db_migrations/0287_delete_vulnerability_id.py renamed to dojo/db_migrations/0288_delete_vulnerability_id.py

@@ -1,7 +1,7 @@
 # Entity-only cutover: drop the legacy Vulnerability_Id store. Vulnerability ids now live entirely in
-# the Vulnerability entity + FindingVulnerabilityReference through-table (created in 0285, backfilled
-# from dojo_vulnerability_id in 0286 — which runs BEFORE this drop). ⚠️ DESTRUCTIVE: drops
-# dojo_vulnerability_id and its data. On upgrading installs, ensure 0286's backfill (or
+# the Vulnerability entity + FindingVulnerabilityReference through-table (created in 0286, backfilled
+# from dojo_vulnerability_id in 0287 — which runs BEFORE this drop). ⚠️ DESTRUCTIVE: drops
+# dojo_vulnerability_id and its data. On upgrading installs, ensure 0287's backfill (or
 # `manage.py migrate_vulnerability_ids` pre-run) has completed before this migration removes the source.
 
 from django.db import migrations
@@ -10,7 +10,7 @@
 class Migration(migrations.Migration):
 
     dependencies = [
-        ("dojo", "0286_backfill_vulnerability_id_entities"),
+        ("dojo", "0287_backfill_vulnerability_id_entities"),
     ]
 
     operations = [