Include acr and amr claims in stateless JWT access tokens

[vharseko]

Summary

This PR adds the authentication context class reference (acr) and the
authentication modules (authModules, i.e. the amr value) to the stateless
JWT access token.

Until now these claims were only available in the id_token, the
/oauth2/userinfo endpoint and the /oauth2/tokeninfo endpoint. The stateless
access token was assembled in StatelessTokenStore.createAccessToken(...) from
a hard-coded claim set with no extension point, so neither the OIDC Claims
Script nor a custom Scope Implementation Class could influence it. As a result,
PEPs / API gateways that need acr/amr were forced to make an extra
/oauth2/tokeninfo round-trip per request.

With this change the claims are written directly into the access token payload,
exactly the same way they are already written into the refresh token in
createRefreshToken(...).

Motivation

• Reported in OpenAM Discussion #1027.
• The stateless access token already carried acr/amr for the refresh
  token but not for the access token — an inconsistency inherited from the
  original ForgeRock code.
• Avoids an extra network round-trip to /oauth2/tokeninfo for downstream
  services that authorize on acr/amr.

Changes

OAuth2 (server)

• StatelessTokenStore.createAccessToken(...):
  • After building the base JwtClaimsSetBuilder, extract acr
    (getAuthenticationContextClassReference()) and authModules
    (getAuthModules()) from:
    • the AuthorizationCode present in the request (authorization_code grant), and
    • the previous RefreshToken present in the request (refresh_token grant),
      which overrides the authorization-code values when present.
  • The acr and authModules claims are added only when a value is
    available, keeping the change additive and backward-compatible.
  • Reuses the existing authCode lookup (already read for the
    realm_access.roles logic); no new imports required — ACR and
    AUTH_MODULES constants were already imported.

Documentation

• admin-guide/chap-openid-connect.adoc: the decoded stateless access token
  example now shows the acr and authModules claims, with a NOTE explaining
  that they appear only when the originating authorization code / refresh token
  carries them (e.g. omitted for the client_credentials grant).

Tests

• StatelessTokenStoreTest (new tests):
  • whenAuthorizationCodePresentAcrAndAmrGetAddedToAccessToken
  • whenRefreshTokenPresentAcrAndAmrGetAddedToAccessToken
  • whenRefreshTokenPresentItOverridesAuthorizationCodeAcrAndAmr
  • whenNoAcrOrAmrAvailableTheyAreNotAddedToAccessToken
  • Shared mock setup extracted into givenBaseProviderSettings().

Behavioral / compatibility notes

• Additive only. When no authorization code or refresh token with acr /
  authModules is available (for example, the client_credentials grant), the
  claims are simply omitted — existing tokens are unaffected.
• Consistent with refresh tokens. The logic and claim names (acr,
  authModules) match createRefreshToken(...).
• No configuration changes, no new scripts, no new provider settings.

How to test

# Unit tests
mvn -pl openam-oauth2 test -Dtest=StatelessTokenStoreTest

Result: Tests run: 6, Failures: 0, Errors: 0, Skipped: 0.

Manual:

1. Configure an OAuth2/OIDC provider with stateless OAuth2 tokens enabled.
2. Obtain an access token via the authorization_code grant after
   authenticating through a chain that yields an acr / auth modules.
3. Decode the JWT access token (or call /oauth2/tokeninfo) and confirm the
   acr and authModules claims are present in the payload.
4. Refresh the token and confirm acr / authModules are preserved from the
   refresh token.

Related

• Discussion: OpenIdentityPlatform/OpenAM #1027