Add ff to ignore mergeability race when creating merged results pipeline

What does this MR do and why?

There is a race between merged results pipeline creation and target branch changes, as both can affect the mergeability status of an MR. When an external mergeability check "wins", the merge request pipeline creation currently falls back to a detached pipeline.

In this MR, we add a feature flag merged_results_pipeline_ignore_target_branch_race, changing this behavior to ignore a failed mergeability check if the merged results ref was successfully updated without conflicts.

The flag is disabled by default.

Part of #469380 (closed)

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Before	After
2025-10-06_10-04-59.mkv	2025-10-06_10-12-16.mkv

How to set up and validate locally

1. In your GDK, add an artificial delay into MergeRequests::MergeabilityCheckService#update_merge_status as follows:

   diff --git a/app/services/merge_requests/mergeability_check_service.rb b/app/services/merge_requests/mergeability_check_service.rb
   index 0e5274267f04..cf5bf1b24f15 100644
   --- a/app/services/merge_requests/mergeability_check_service.rb
   +++ b/app/services/merge_requests/mergeability_check_service.rb
   @@ -128,6 +128,15 @@ def update_merge_status
    
          if merge_to_ref_success && can_git_merge?
            merge_request.mark_as_mergeable
   +
   +        if Gitlab::ApplicationContext.current['meta.root_caller_id'] == "POST /api/:version/projects/:id/merge_requests/:merge_request_iid/pipelines"
   +          100.times do
   +            break unless MergeRequest.find(merge_request.id).can_be_merged?
   +
   +            sleep 1
   +          end
   +        end
   +
            reload_merge_head_diff
            true
          else

2. Make sure your .gitlab-ci.yml is configured for merge request pipelines

3. On a merge request, press the Run pipeline button. Due to the patch above, the pipeline creation will be delayed for about 100 seconds or race has actually occurred.

4. Within the next 100 seconds, push a change to the MR's target branch (e.g. master or main)

Observe:

• When the feature flag merged_results_pipeline_ignore_target_branch_race is disabled, a detached pipeline is created
• When the feature flag is enabled, a merged_results pipeline is created

When testing, remember that feature flag changes can take a while to propagate to all processes due to a multi-layered cache. Any time the feature flag is flipped, the old flag value's behaviour may persist for a bit, but they will eventually stabilize to the expected value.