Sync issues bigint indexes batch two

What does this MR do and why?

Creates the bigint indexes for batch two of the issues integer ID to bigint conversion synchronously, tracked in #629828.

This is the second MR for batch two and is stacked on top of the async preparation MR (!255948 (merged)). The previous MR queued the 13 indexes for asynchronous creation; this MR creates them synchronously so that instances where the async worker has not built them (or where a build was left invalid) end up with the indexes in place.

Batch two covers id on its own. See the agreed batch split.

Important

This MR must not merge until the asynchronous index builds are confirmed complete on GitLab.com. Each migration is a no-op when the index already exists and is valid, so once the async builds have finished these run instantly. If it merges before the async builds finish, the indexes are built synchronously during deployment on a very large table.

One migration per index

Each index gets its own migration (13 total), mirroring the batch one sync creation MR. This keeps individual migration runtimes small and lets each index be retried independently.

Each migration uses add_concurrent_index, which:

• Skips creation when the index already exists and is valid (the expected path once the async builds finish).
• Rebuilds the index when the existing one is invalid, so a failed async build is self-healed.

Indexes created (13)

All against id_convert_to_bigint, created under bigint_index_name(<original name>):

Migration	Index
20260917090001	issues_pkey (unique; becomes the primary key during the swap)
20260917090002	index_issues_on_id_and_weight
20260917090003	index_issues_on_namespace_id_created_at_id_state_id
20260917090004	index_issues_on_namespace_id_relative_position_id_state_id
20260917090005	index_issues_on_namespace_id_updated_at_id_state_id
20260917090006	index_issues_on_milestone_id_and_id
20260917090007	idx_issues_on_project_id_and_created_at_and_id_and_state_id
20260917090008	idx_issues_on_project_id_and_due_date_and_id_and_state_id
20260917090009	idx_issues_on_project_id_and_rel_position_and_id_and_state_id
20260917090010	idx_issues_on_project_id_and_updated_at_and_id_and_state_id
20260917090011	index_issues_on_project_id_closed_at_desc_state_id_and_id (keeps closed_at DESC NULLS LAST)
20260917090012	idx_open_issues_on_project_and_confidential_and_author_and_id
20260917090013	index_open_issues_on_namespace_id_confidential_author_id_id

The index definitions match the async preparation MR exactly, so add_concurrent_index detects the async-built index and skips it.

Migration output

db/structure.sql is unchanged: these indexes are on id_convert_to_bigint, which is not part of the committed schema. (Danger flags "new migrations added but db/structure.sql wasn't updated"; this is expected for ID conversions.)

Follow-up

Once these indexes exist, further MRs add the incoming foreign keys on issues.id, perform the swap (including the primary key), and drop the temporary objects. Batch two targets the 19.5 milestone end to end.

MR acceptance checklist

• Database review requested — synchronous index creation matching previously prepared async indexes.