[Feature] pattern matching for Client JWT sub

Using client JWTs to authenticate clients—such as those from GitHub—offers significant value but comes with certain limitations.

The subject (sub) claim in the token varies depending on the context in which the action is executed. For example:

• When targeting an environment: repo:octo-org/octo-repo:environment:Production
• When targeting a branch: repo:octo-org/octo-repo:ref:refs/heads/demo-branch

GitLab follows a similar pattern for generating the sub claim.

Reference: GitHub Docs – Example Subject Claims

Currently, the sub value configured in the client JWT must exactly match the sub in the incoming token. As a result, users may need to create multiple client JWT configurations to cover all possible subjects—up to the configured limit of 10 entries.

To improve flexibility and reduce this overhead, it would be highly beneficial if UAA supported pattern matching in the sub claim. For example:

• repo:octo-org/octo-repo:ref:refs/heads/*
• repo:octo-org/octo-repo:environment:*

Start by tracing the client JWT authentication path where the incoming token's sub claim is compared with configured client JWT subjects. Review how subject values and the ten-entry limit are represented, then define and test the supported pattern semantics so branch and environment examples match without weakening authentication checks.