Vulnerability UUID Migration Phase 4: Transition GitLab to use new_uuid
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=587804)
</details>
<!--IssueSummary end-->
## Problem
After `new_uuid` is fully populated and has a NOT NULL constraint, we need to transition all GitLab code to use `new_uuid` instead of the old `uuid` column for vulnerabilities.
## Implementation
1. Audit all code paths that reference `vulnerabilities.uuid`
2. Update code to read from `new_uuid` instead of `uuid`
3. Update any indexes, foreign keys, or constraints that reference `uuid`
4. Feature flag the transition for safe rollout
5. Update API responses and GraphQL schemas as needed
6. Ensure backward compatibility during transition period
## Acceptance Criteria
- [ ] All code paths updated to use `new_uuid`
- [ ] Feature flagged for safe rollout
- [ ] API/GraphQL compatibility maintained
- [ ] No regressions in functionality
## Dependencies
- Blocked by Phase 3 (NOT NULL constraint must be in place)
## Related
- Part of Vulnerability UUID migration series
- #587624 - Phase 1: Start populating new_uuid
issue