Add batched background migration to backfill default branches to security tracked contexts

What does this MR do and why?

This MR implements a batched background migration to backfill the security_project_tracked_contexts table with default branch entries for all existing projects that have vulnerabilities.

This addresses the requirement from #556014 to initialize the table with default branch information before enabling multiple branch tracking for vulnerabilities.

How to set up and validate locally

1. Ensure you have projects with vulnerabilities in your local environment
2. Run the migration: rails db:migrate
3. Check that the batched background migration is queued: rails runner "puts Gitlab::Database::BackgroundMigration::BatchedMigration.where(job_class_name: 'BackfillSecurityProjectTrackedContextsDefaultBranch').count"
4. Process the migration: rails runner "Gitlab::Database::BackgroundMigration::BatchedMigrationRunner.new(connection: ApplicationRecord.connection).run_entire_migration(Gitlab::Database::BackgroundMigration::BatchedMigration.where(job_class_name: 'BackfillSecurityProjectTrackedContextsDefaultBranch').first)"
5. Verify records were created: rails runner "puts Security::ProjectTrackedContext.where(is_default: true).count"

MR acceptance checklist

• I have included changelog trailers, or none are needed. (Note: Changelog not needed for background migrations)
• I have added/updated documentation, or it's not needed.
• I have properly separated EE content from FOSS, or this MR is FOSS only.
• I have added information for database reviewers in the MR description, or it's not needed.

Database Review

This MR adds a batched background migration that:

• Target table: projects (iterating over projects with vulnerabilities)
• Destination table: security_project_tracked_contexts (inserting default branch records)
• Batch size: 1000 projects per batch, 100 projects per sub-batch
• Scope: Only projects where project_settings.has_vulnerabilities = true
• Conflict handling: Uses ON CONFLICT DO NOTHING to handle existing records gracefully
• Performance: Uses efficient bulk INSERT with proper indexing on the target table

The migration is safe to run as:

1. It only reads from existing tables (projects, project_settings)
2. It only inserts into the new security_project_tracked_contexts table
3. It handles conflicts gracefully without modifying existing data
4. It processes data in small batches to avoid long-running transactions

Related Issues

Closes #556014