Accept stateless JWTs in git-over-HTTPS and API auth

What does this MR do and why?

This wires the StatelessAccessToken JWT from !254063 (merged) into GitLab's existing auth acceptance paths, so it works alongside Doorkeeper OAuth tokens for both git-over-HTTPS and API requests.

Both entry points follow the same pattern: the CE method's body is extracted so EE can override it, try the stateless JWT check first, and fall back to the original chain when the credential isn't a stateless JWT or the duo_workflow_use_token_issuer feature flag is off.

• Gitlab::Auth#git_client_checks (extracted from find_for_git_client), overridden in EE to try stateless_access_token_check before falling back to super.
• Gitlab::Auth::AuthFinders#resolve_access_token (extracted from access_token), overridden in EE to try find_stateless_access_token before falling back to super.

Both new EE methods are named and defined separately from oauth_access_token_check and find_oauth_access_token rather than nested inside them. A StatelessAccessToken isn't an OAuth-issued credential — it's minted directly server-side, not obtained through an OAuth grant — so folding it into the OAuth-named methods would misrepresent what it is.

This is one of two MRs split out from a larger original change so each piece reviews independently. It depends on !254063 (merged) (the StatelessAccessToken class, already merged) but not on the sibling issuance MR (!253733 (merged)); the two review and merge in parallel.

References

• Related to #617039 (closed)
• Related to #617040 (closed)
• Depends on !253247 (closed) (substrate)

Screenshots or screen recordings

Not applicable — backend-only change, no UI.

How to set up and validate locally

1. Ensure !253247 (closed) (the substrate MR) is present on this branch.
2. Enable the feature flag for a test user: Feature.enable(:duo_workflow_use_token_issuer, User.find_by(username: 'your_username')).
3. Run the updated specs:

   bundle exec rspec ee/spec/lib/ee/gitlab/auth_spec.rb ee/spec/lib/ee/gitlab/auth/auth_finders_spec.rb

4. Full end-to-end validation (a real request authenticated with a JWT) needs the sibling issuance MR too, since nothing mints these JWTs yet on its own.

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.