Optimize factory usage in merge_request_presenter_spec

What does this MR do and why?

This MR replaces create with build_stubbed in ee/spec/presenters/merge_request_presenter_spec.rb to optimize factory usage as recommended in our handbook. This spec is part of the list .rubocop_todo/rspec/factory_bot/avoid_create.yml. It was verified that database persistence is not needed using the factory doctor command FDOC=1 bin/rspec ee/spec/presenters/merge_request_presenter_spec.rb.

Factory Usage Optimization Results

Before optimization:

• Factory time: 13.342s (47.24% of total time)

After optimization:

• Factory time: 7.257s (30.24% of total time)

Improvement:

• Factory time reduced by: 6.085s
• Factory time percentage reduced by: 16.99%
• Overall factory usage improvement: ~45.6%

What changed

The top-level let(:merge_request) was changed from create to build_stubbed since the vast majority of tests only read presenter attributes and do not require DB persistence.

Local create overrides were added in the three contexts that genuinely need a persisted record:

• #issue_keys — calls merge_request.update!
• #api_status_checks_path "with the user authenticated" — creates real external_status_check records with FK to the MR
• #require_saml_auth_to_approve security policy context — creates approval_merge_request_rule and scan_result_policy_violation with FK to the MR

Factory Doctor Output

[TEST PROF INFO] FactoryDoctor report

Total (potentially) bad examples: 23
Total wasted time: 00:07.113

MergeRequestPresenter (./ee/spec/presenters/merge_request_presenter_spec.rb:5) (54 records created, 00:07.113)
  returns empty array for approver_groups (line 357) – 1 record created, 00:01.465
  uses the root group for SSO path and token (line 236) – 12 records created, 00:00.584
  uses the root group for SSO path and token (line 245) – 9 records created, 00:00.202
  is expected to eq nil (line 190) – 1 record created, 00:00.243
  ...and 19 more examples

References

Relates to: #378910

MR acceptance checklist

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