Add advanced groups_finder to GraphQL and API

What does this MR do and why?

Routes the GraphQL group resolvers and the /api/v4/groups family through Namespaces::GroupsFinder, behind the namespaces_advanced_groups_finder feature flag.

Namespaces::GroupsFinder is a router: it tries Search::AdvancedFinders::GroupsFinder (Elasticsearch, itself behind advanced_groups_finder_elasticsearch) and falls back to the existing GroupsFinder whenever any requested filter or the sort is not expressible in Elasticsearch, or the match set is too large to sort correctly. With both flags off, nothing changes.

Two call sites are touched:

• Resolvers::Namespaces::BaseGroupsResolver#resolve_groups. Only Resolvers::GroupsResolver and Resolvers::Namespaces::AdminGroupsResolver reach it: the organization, nested, shared and user group resolvers all override resolve_groups without calling super and use their own finders, so they are unaffected. Every argument name and default is preserved, including sort: 'name_asc', allow_similarity_sort, ADMIN_RESTRICTED_SORTS and unpack_negated_args. No schema change.
• API::Groups#find_groups, shared by /groups, /subgroups, /descendant_groups, /shared and /invited_groups. Sorting still happens in order_groups, which reorders whichever relation comes back, so the two finders are interchangeable there.

Namespaces::GroupsFinder and the Elasticsearch filters it relies on are already on master, so this MR is only the two call sites plus the flag that gates them.

Elasticsearch eligibility is narrower than the flag suggests, and worth stating for the rollout issue. A request needs a search term, since an unfiltered listing exceeds RESULT_LIMIT and would be discarded after the round trip. On REST, find_groups defaults all_available to can_read_all_resources?, and all_available: false is not expressible in Elasticsearch, so REST reaches it only for admins and auditors.

Because specs enable feature flags by default, spec/requests/api/groups_spec.rb, ee/spec/requests/api/groups_spec.rb and the resolver specs now exercise Namespaces::GroupsFinder end to end. That is the real verification here.

Neither flag is enabled anywhere. Rollout is blocked on the instrumentation MR landing first, so the backend shift is measurable before any traffic moves.

References

Related to #607020

Screenshots or screen recordings

No user-facing change. Same results, same order, same GraphQL schema.

How to set up and validate locally

1. Enable the flag: Feature.enable(:namespaces_advanced_groups_finder)
2. Query groups over GraphQL and GET /api/v4/groups?search=..., with and without the flag, and confirm identical results and ordering.
3. With Elasticsearch set up in GDK, also enable Feature.enable(:advanced_groups_finder_elasticsearch) and confirm that an unsupported filter (min_access_level, owned, with_statistics) falls back to PostgreSQL rather than returning partial results.

MR acceptance checklist

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

• I have evaluated the MR acceptance checklist for this MR.