Draft: Finding UUID Migration Phase 5: Drop old uuid column

What does this MR do and why?

Implements Phase 5 of the Finding UUID migration (#587801).

This is the final phase - drops the old uuid column after the code transition is complete.

Decision: Keep new_uuid as permanent name

We decided to keep new_uuid as the permanent column name rather than renaming it to uuid. This avoids significant complexity and risk:

• No need for attribute aliases/accessors during rename
• No issues with raw SQL queries during transition
• No foreign key relationship complications
• Simpler rollback if issues arise

Changes

Migration

1. Remove old uuid column (20260127165106)
   • Drops the now-unused uuid column
   • new_uuid becomes the only UUID column

Prerequisites

Before this MR can merge, all previous phases must complete:

• Phase 1 (!220835 (merged)) - Populate new_uuid for new findings
• Phase 2 (!220866) - Backfill new_uuid for existing findings
• Phase 3 (!220869) - Add NOT NULL constraint
• Phase 4 (!220872) - Transition code to use new_uuid
• Feature flag use_new_uuid_for_findings fully rolled out
• Feature flag cleanup (remove flag, code always uses new_uuid)

Dependencies

This MR targets the Phase 4 branch and cannot be merged until all previous phases complete.

Migration Plan

Phase	Issue	MR	Status
1	#587625 (closed)	!220835 (merged)	In Review
2	#587798	!220866	Pipeline Running
3	#587799	!220869	Pipeline Running
4	#587800	!220872	Draft
5	#587801	This MR	Draft

Post-Migration State

After all phases complete:

• Single new_uuid column containing context-aware UUIDs
• All code uses new_uuid
• Feature flag removed
• Old uuid column dropped

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist.

Relates to #587801