Skip fine-grained token enforcement for bot users

What does this MR do and why?

Fine-grained token enforcement currently applies to every legacy personal access token, including the ones owned by bot users. That breaks service account tokens and group and project access tokens, and there is no fine-grained version of these tokens yet, so owners can't create a replacement.

This affects both kinds of enforcement:

• GitLab.com (group setting): legacy bot tokens are denied on the enforced group's resources. A customer had an outage because of this (see the issue).
• Self-Managed (instance setting): after the enforcement date, nobody can create or rotate a group access token, project access token, or service account token, because PersonalAccessTokens::CreateService and RotateService reject every legacy token.

This MR skips enforcement when the token owner is not a human user, in AuthorizeGranularScopesService, PersonalAccessTokens::CreateService, and PersonalAccessTokens::RotateService. Only human users have a supported way to create a fine-grained token today. The docs now say that enforcement doesn't cover these tokens.

Once service accounts and resource access tokens support fine-grained tokens, we can bring them under enforcement again. We should give groups that already enforce a separate opt-in or date when that happens, so they don't break a second time.

Scope decision: service accounts from other groups

A service account provisioned by group A that is a member of enforced group B also skips B's enforcement with this change. We could limit the exemption to service accounts provisioned by the enforcing root namespace (user_detail.provisioned_by_group_id). I went with the simpler check because the exemption is temporary and the goal is to stop the breakage. Happy to narrow it if reviewers prefer.

References

• #616442
• Service account fine-grained tokens: #591779
• Fine-grained resource access tokens: #471174

Screenshots or screen recordings

Not applicable, backend change only.

How to set up and validate locally

1. Create a group access token for a top-level group and check that GET /api/v4/groups/:id returns 200 with it.
2. In the group, go to Settings > General > Permissions and group features and require fine-grained tokens from today.
3. Repeat the request with the group access token. It still returns 200. Before this change it returned 403 insufficient_granular_scope.
4. Repeat the request with a legacy personal access token of a human group member. It is still denied.
5. For the instance setting: in Admin > Settings > General > Account and limit, require fine-grained tokens from today, then create a new project access token. It succeeds. Creating a legacy personal access token for a human user is still rejected.

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.