Backfill existing group milestones in Advanced Search

What

Group milestones created before #630654 (closed) turned on indexing have no documents. This issue backfills them.

Implemented in !261588 (merged).

Changes

• Add the ReindexMilestones Advanced Search migration, using Search::Elastic::MigrationDatabaseBackfillHelper: batch size 10,000, a 1-minute throttle delay between batches, respects limited indexing, preloads the project namespace and the group's namespace settings. Project milestone documents are rewritten in place with the same _id and routing, so nothing is duplicated.
• The migration reindexes all milestones rather than filtering to group milestones only. Filtering by project_id IS NULL makes batches scan past project milestones instead of using a plain primary key range: the first batch read and discarded 181,131 rows to return 1,000 (about 88,400 buffers, 13,655 ms on a cold Database Lab clone), against 215 buffers and 5.8 ms per batch for the unfiltered primary key range. gprd has about 2.82 million milestones, about 569,000 of them group milestones. Query plan: https://console.postgres.ai/shared/8ccf384b-d944-44a8-bc7c-737da0502e83
• The migration is skipped on GitLab.com. ReindexAllMilestonesFromDatabase (from !258497 (merged)) already reindexes every milestone there, and because it runs after !257456 (merged) is deployed, it indexes group milestones too. That migration only runs on GitLab.com, so self-managed and Dedicated need this one.
• Add the changelog entry for this user-facing change.

Depends on

!257456 (merged) (closes #630654 (closed)), deployed. Done: it merged on 2026-10-07 and is in production. Running this migration earlier would bake in orphaned or duplicate documents: group deletes cascade without callbacks, and transfers change routing, so any group milestone indexed before the sync code exists can't be repaired later.

Part of #428589. Based on the implementation plan.