Fix order-dependent failure in ApprovalGroupedCodeOwnerRule spec

What does this MR do and why?

Fixes an order-dependent failure in ee/spec/models/merge_requests/approval_grouped_code_owner_rule_spec.rb.

The spec defined merge_request with let_it_be_with_reload. That reuses the same MergeRequest object in every example and only calls reload on it. reload doesn't clear the approval_state memoized in EE::Approvable#approval_state, and ApprovalState#overall_approver_ids is memoized too. So the first example that checks approvals caches the approver IDs, and later examples see that stale set:

• If is not approved while an underlying rule still needs approvals runs first, it caches {approver1}, and is approved once every underlying rule is approved fails.
• If the order is reversed, it caches {approver1, approver2}, and the "not approved" example fails.

This means the file fails with every seed. It only looked flaky in CI because the retry runs the failing example alone in a new process, where it passes.

The fix switches to let_it_be_with_refind, so each example gets a fresh MergeRequest object with no memoized approval state.

CI evidence: in 96 tier 3 MR pipelines on 2026-10-13/14, this spec failed in the first RSpec process of rspec-ee unit pg17 lanes in 95 pipelines, and passed every time when retried alone in a new process.

References

• Related tail-latency issue: #633791 (closed)

Screenshots or screen recordings

Not applicable, this is a spec-only change.

How to set up and validate locally

This seed runs the "not approved" example before the "approved" one, so it reproduces the failure on master:

bin/rspec ee/spec/models/merge_requests/approval_grouped_code_owner_rule_spec.rb --seed 64942

• On master: 12 examples, 1 failure at approval_grouped_code_owner_rule_spec.rb:111 ("is approved once every underlying rule is approved").
• On this branch: 12 examples, 0 failures.

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.