feat(oauth2): populate groups claim in client_credentials tokens

[carlesarnal]

Overview

Add a ClientCredentialsClaims sub-struct to the Client definition, allowing static clients to declare identity claims (starting with groups) that are included in tokens issued via client_credentials.

What this PR does / why we need it

PR #4583 added client_credentials grant support and lists groups as a supported scope. However, the scope is only accepted (not rejected) — the Groups field in the claims struct is never populated, so tokens never contain a groups claim regardless of the scope requested.

This is because client_credentials has no upstream connector or user involved, so there is no source for group membership. This PR adds a clientCredentialsClaims sub-struct to static client definitions, keeping identity attributes separate from core Client fields (ID, secret, redirect URIs).

Design decision: Per reviewer feedback, identity attributes are scoped to a dedicated ClientCredentialsClaims struct rather than added as top-level fields on Client. This avoids mixing application identity with user-like identity attributes and provides a clean extension point for future claims (email, custom attributes) without each addition leaking into the client definition.

Changes:

1. storage/storage.go — Added ClientCredentialsClaims struct with Groups field, and an optional ClientCredentialsClaims pointer on Client
2. server/handlers.go — In handleClientCredentialsGrant, populate claims.Groups from client.ClientCredentialsClaims.Groups when the groups scope is requested
3. server/handlers_test.go — Added two test cases:
   • Client with clientCredentialsClaims.groups + groups scope → groups appear in token
   • Client without clientCredentialsClaims + groups scope → no groups in token (no regression)

Configuration example:

staticClients:
  - id: my-service
    name: My Service
    secret: "..."
    clientCredentialsClaims:
      groups:
        - admin-group
        - dev-group

Why this matters:

Applications that use the groups claim for RBAC — such as Apicurio Registry — cannot authorize client_credentials tokens for write operations without groups. The Apicurio Kafka SerDes libraries only support client_credentials (they hardcode grant_type=client_credentials), so this is a blocking issue for Kafka schema registry use cases.

Testing:

• go test ./server/... -run TestHandleClientCredentials — all 10 cases pass (8 existing + 2 new)
• Manually tested on an OpenShift cluster with a patched Dex image: client_credentials tokens now include groups and Apicurio Registry successfully resolves RBAC roles — write operations return 200 instead of 403

Fixes #4690

[nabokihms]

Overall, looks good. The only thing required is the storage code.