Deflake granular token permissions spec for group MRs

What does this MR do and why?

Backports the GET /groups/278964/merge_requests granular-token spec fix from !226653 (merged) to 19-0-stable-ee. That change is already on master and 19-1-stable-ee, so only 19-0-stable-ee is affected.

The granular token example used the shared let_it_be() directly as its boundary object:

let(:boundary_object) { group }

A sibling example ("referencing from parent group") reparents that shared group via group.update!(parent_id: parent_group.id). reload: refreshes column attributes but not the strong-memoized root_ancestor, so once that sibling runs before the granular example (RSpec randomizes order) the granular example resolves root_ancestor to a rolled-back namespace and fails with ActiveRecord::RecordNotFound when looking up its NamespaceSetting.

The fix re-finds the group so the boundary object is a fresh instance:

let(:boundary_object) { Group.find(group.id) }

How was this tested?

Reproduced and verified locally by forcing the polluting order:

bundle exec rspec spec/requests/api/merge_requests_spec.rb \
  -e "GET /groups/278964/merge_requests" --order defined

• Before: 1 failure (ActiveRecord::RecordNotFound).
• After: 0 failures.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
• The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
• The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
• Required labels have been applied to this merge request
  • severity label and bug subtype labels (if applicable)
  • If this MR fixes a bug that affects customers, the customer label has been applied.
• This MR has been approved by a maintainer (only one approval is required).
• Ensure the e2e:test-on-omnibus-ee job has succeeded, or if it has failed, investigate the failures. If you determine the failures are unrelated, you may proceed. If you need assistance investigating, request help in the #s_developer_experience Slack channel to confirm the failures are unrelated to the merge request.