Clean up deployments bigint conversion

What does this MR do and why?

This is the 19.4 release N+2 cleanup for the deployments table, per the 3-release process described in https://docs.gitlab.com/development/database/avoiding_downtime_in_migrations/#remove-the-trigger-and-old-integer-columns-release-n--2.

Both bigint conversion phases for deployments finished in #551602 (closed):

• Phase one (id, environment_id) swapped in GitLab 18.11.
• Phase two (project_id, user_id) swapped in GitLab 19.3 via !248015 (merged), with the temporary indexes/foreign key dropped in !248030 (merged).

This migration removes what phase two intentionally left behind:

• The four old integer shadow columns: id_convert_to_bigint, environment_id_convert_to_bigint, project_id_convert_to_bigint, user_id_convert_to_bigint.
• The synchronization trigger trigger_a2cc844b73ed.

It uses cleanup_conversion_of_integer_to_bigint, the shared helper for this exact 3-release process, so no manual DDL is written here.

down is a no-op. Restoring the shadow columns and trigger would reactivate the historical deployments bigint-conversion down-migration chain: phase one's DropTmpBigintIndexesAndFkForDeploymentsPhaseOne drops a temporary primary-key index in up but has an empty down, so any later migration rollback that reaches that point hits a missing index. CI confirmed this — every background_migration RSpec shard failed with PG::UndefinedTable on bigint_idx_f39eaa4e73c3352e7c92 once this migration's down recreated the shadow columns and a finalized-BBM spec rolled the schema back through it. Making down a no-op avoids reviving that broken chain.

Scope

Only the deployments table is cleaned up here. deployment_clusters and deployment_merge_requests are deliberately excluded and remain tracked by the parent issue below; this MR does not close it.

The ignore_column declarations in app/models/deployment.rb, app/models/deployment_cluster.rb, and app/models/deployment_merge_request.rb are untouched. Removing them is the next-release (N+3) step, tracked by #551606 (closed).

db/structure.sql

db/structure.sql is unchanged. It already represents the final schema (no shadow columns, no trigger) because new installations start from bigint directly. Only existing instances that ran the original bigint initialization migration carry the shadow columns and trigger, and this migration is what removes them there.

Because down is a no-op, the db:check-migrations rollback simulation does not touch db/structure.sql either, so no diff is expected there.

Rollback

down is a no-op (see above). This means the migration is release-only: if it needs to be reverted, that requires a separate migration to remove the version and code review of the actual consequences, rather than a plain db:migrate:down.

Wraparound safety

The migration is guarded by WraparoundAutovacuum#can_execute_on?. If a wraparound-prevention vacuum is active on deployments when this runs on GitLab.com, it silently skips (logged, not raised). Rails will still record the migration version as applied, so a skip requires a follow-up retry migration in a later release.

Related issues

• Related to #551605 (closed) (tracks the remaining deployment_clusters and deployment_merge_requests cleanup; not closed by this MR)
• Staging evidence: #611715

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Database review

Requesting db:gitlabcom-database-testing since production-like database testing is the meaningful verification for the old conversion artifacts (the local/canonical schema never has the shadow columns to exercise this against).