Clarify the purpose of the User assignment in the Client Credentials grant type

Picking this up 🫡

Thanks @cobadger for the detailed review, and @alex ua for the original patch. I have pushed changes on top of the existing branch addressing all four threads.

• Super user in the test base. Fixed in AuthorizedRequestBase rather than only in ClientCredentialsTest, as suggested. The first account created in an empty user table becomes uid 1, and SuperUserAccessPolicy then short-circuits every access check. Worth noting that RefreshTokenTest and OpenIdConnectTest pass unchanged once they get an ordinary account, so they were not relying on the bypass either. The base fix therefore hardens all three with no behaviour change, and makes the per-subclass override unnecessary.
• Deterministic uid 1 for SuperUserTest. It now loads uid 1 explicitly instead of depending on creation order, which also removes the ambiguity around the kernel reboot in testSuperUser(). The existing assertEquals('1', ...) stays as an intentional guard.
• Assertion placement. Moved out of testSaveConsumerWithNewSecret() into its own testClientCredentialsFieldDescriptions(), with a fixture holding only what the descriptions need.
• The second half of the issue. The role guidance went on the scopes field rather than growing the user_id description further, as suggested.

On that last point, I confirmed the asymmetry locally before wording it. With a Role granularity scope pointing at a role the selected user does not hold, the same token gives:

route requiring _permission: 'access administration pages'  ->  200
route requiring _role: 'repro_editor'                       ->  403
getRoles() reports only ["authenticated"], hasRole() is FALSE

So permission checks pass while role membership checks quietly fail, with nothing to explain why. Role::getPermissions() contributes the role's permissions unconditionally, while TokenAuthUser::getRoles() intersects with the user's real roles.

To be explicit about scope: this MR now resolves both halves of the report, the User field wording and the permission-versus-role asymmetry. Full test suite passes locally (90/90) and PHPCS is clean; the PHPStan finding in Oauth2ClientCredentialsTokenCreateForm.php is pre-existing on 6.1.x and untouched here.

Cross-referencing #3589432: Access denied in JSONAPI for OAuth users, which documents the same asymmetry on the scope form. Different audience, same facts, so the wording in both should stay consistent.

Picking this up - will actually check mid-week.

Working on this today.

The changes all look good to me.

I made a quick wording change to the Scopes field description to address Alex's point 4 — the previous text conflated the unconditional permission grant with the separate role-membership check. The pipeline is green after a rebase.

Cross linking the related #3589432: Access denied in JSONAPI for OAuth users, which adds scope-form descriptions, a README section, and additional tests for the behavior documented here.

Drafted with help of an LLM

Nice work all!