OAuth authorization treats space-separated scopes as one scope #30348

Bug

On current main (54343aa685ae8f33159d2f485ec4a57bad5c574a), the OAuth authorization page splits the scope query parameter only on commas. A standard space-separated request such as scope=READ_BOOKING%20READ_PROFILE is sent to generateAuthCode as ["READ_BOOKING READ_PROFILE"], rather than two scope tokens.

Source: authorize-view.tsx.

These names are valid individual values in this fork's AccessScope enum. The combined string is not. Both the manual Allow action and trusted-client auto-authorization use this incorrectly parsed array.

Reproduction and expected behavior

1. Open the authorization page for a registered OAuth client with scope=READ_BOOKING%20READ_PROFILE and its valid redirect URI.
2. Authenticate and approve, or use a trusted client.
3. Inspect the generateAuthCode mutation input: it contains one combined string.

Expected: scopes: ["READ_BOOKING", "READ_PROFILE"]. Existing comma-separated requests must continue to work, and unknown tokens must remain available for server-side validation rather than being silently removed.

A component regression rendering the real Authorize component reproduces this in both paths. Against the original parser, six of the initial fourteen cases fail; splitting comma/space-delimited tokens resolves those failures.

Relationship to hosted MCP issue

Discovered while investigating #30344. We independently confirmed that the hosted MCP consent redirect emits a space-separated scope parameter. This issue tracks the independently reproducible Cal.diy parser defect, not the hosted client's registration mismatch: Cal.com production source/configuration differs, and fixing this fork does not establish that #30344 is resolved.