feat(identity): let extensions register their own UCP OAuth scopes

[Sebastian Hölscher (HoelShare)]

The grantable scopes were a private class constant on ShopwareIdentityLinkingAdapter, so a plugin adding a UCP capability of its own had no way to make its scope grantable: the authorization request threw Unsupported OAuth scope. A consent flow that catches that exception has already burned its one-time handle by then, so the buyer is told the authorization link expired -- indistinguishable from a real expiry, and two consent links were lost to it before the cause was found.

UcpOAuthScopeRegistry now merges the plugin's own scopes with those returned by every service tagged swag_agentic_commerce.ucp.oauth_scope_provider, the same tagged-iterator mechanism the product-export providers already use. The adapter advertises the merged set in scopes_supported on /.well-known/oauth-authorization-server and validates against it, so an agent can discover a scope before requesting it.

The three built-in scopes are unchanged, an empty scope request still expands to every supported scope, and an unregistered scope is still rejected -- now with the supported set named in the message, which is what made this hard to diagnose.

AbstractUcpOAuthScopeProvider is the plugin's second public PHP extension point and is documented in docs/public-api-boundaries.md.

[Björn Meyer (BrocksiNet)]

Should an omitted scope continue to grant only the three built-in scopes, with extension scopes requiring an explicit request? Expanding it to every registered scope means installing an extension also broadens the permissions granted to existing clients that omit scope, even though their authorization requests haven't changed.

[Sebastian Hölscher (HoelShare)]

Good point Björn Meyer (@BrocksiNet). I've adjusted so only the core scopes are granted!