Allow enabling auto-merge on a preparing merge request

What does this MR do and why?

PUT .../merge_requests/:iid/merge with auto_merge: true right after POST /merge_requests usually returns 405: the MR is still preparing, so the conflict check can't resolve (checking) and no auto-merge strategy is available. Once prepared, the same call returns 200.

Behind auto_merge_skip_conflict_check, the when-checks-pass strategies (merge_when_checks_pass, add_to_merge_train_when_checks_pass) skip the conflict check in all merge states, so auto-merge can be enabled right after creation. This also lets it be enabled on a known conflict (cannot_be_merged), reversing !222317 (merged) — safe because #process still guards with mergeable?(use_cache: false), so a conflicted MR never merges until the conflict clears (e.g. resolved on the target side). The immediate merge_train strategy is unaffected. Full removal of the recheck_merge_status? gating is tracked in #606290 (closed).

Related to #473054.

Feature flag

auto_merge_skip_conflict_check (gitlab_com_derisk, default off). Rollout: #605960.

• On: conflict check skipped in all merge states → auto_merge: true on a preparing/conflicted MR sets auto-merge (200).
• Off: unchanged — skipped only while rechecking → 405 on a preparing MR.

Testing

• spec/models/merge_request_spec.rb — #skipped_auto_merge_checks skips the conflict check for both when-checks-pass strategies when the flag is on (independent of merge status), recheck-only when off.
• spec/requests/api/merge_requests_spec.rb — "MR still preparing and a pipeline is being created": flag on → 200 + auto-merge set; flag off → 405.
• spec/services/merge_requests/merge_orchestration_service_spec.rb — #can_merge? on a cannot_be_merged MR: flag on → true (strategy available), flag off → false.

MR acceptance checklist

• Tests added for both flag states.
• No changelog entry (change is behind a disabled-by-default flag).