Restore admin-level user data read access for auditors in Users API

What does this MR do and why?

!230315 (merged) changed the gating for admin-level user data in the Users API and UsersFinder from can_read_all_resources? / can_admin_all_resources? to can?(:read_admin_users). Auditors have read_all_resources but not read_admin_users, so they regressed to the fetching basic user attributes, losing access to user emails and other admin-only fields.

This MR restores the auditor path at the four sites that previously used can_read_all_resources? by OR-ing it with the new permission. The two sites that were originally can_admin_all_resources? are left as read_admin_users so auditors gain no privileges they did not have before.

References

Custom role email visibility differs between UI... (#594499)

Screenshots or screen recordings

$ curl --header "PRIVATE-TOKEN: <glpat-supersecret>" --url "http://localhost:3000/api/v4/users/1"

{"id":1,"username":"root",..."email":"gitlab_admin_f5dc1e@example.com"...}%

How to set up and validate locally

1. Login as an auditor user

   You can create one by running FactoryBot.create(:auditor, username: 'myauditoruser', email: 'myauditoruser@example.com', password: 'mysecretpassword123') in Rails console

2. Create a legacy personal access token with read_api scope (docs)

3. Call GET /api/v4/users/:id using the token:

   $ curl --header "PRIVATE-TOKEN: <token>" --url "http://localhost:3000/api/v4/users/1"

4. Verify the response uses the admin-level entity — each user object includes email, is_admin, created_at, two_factor_enabled, and other admin-only fields. Before the fix, these fields would be absent.

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.