[feature] Operator-supplied OAuth client definitions for hosted deployments #2382

Self-hosted deployments need to supply their own OAuth 2.0 client definitions without adding deployment-specific providers to Executor's built-in first-party list. Could the host expose one supported, operator-controlled configuration seam for this?

At v2 revision b630c1eaf4f345cc0df60eeb9435b1e339264ce4, apps/hosted/server/src/implementation/first-party-oauth.ts has a reviewed built-in list and an E2E-only EXECUTOR_TEST_OAUTH_CLIENT_DEFINITIONS setting. Production hosts reject that setting. Client credentials already come from separate EXECUTOR_OAUTH_<ID>_CLIENT_ID and EXECUTOR_OAUTH_<ID>_CLIENT_SECRET settings.

Proposed behavior:

• An operator supplies additional definitions through a production configuration surface, validated against the existing FirstPartyOAuthClientDefinition contract. A definition names its authorization server, token authentication/exchange format, allowed/default scopes, and credential placement hosts. It contains no client credentials.
• Credentials remain separate secrets. Existing duplicate-ID, missing/partial credential, endpoint, scope and placement checks remain enforced. Invalid settings fail startup without printing secret values. Operator definitions cannot silently replace a built-in ID.
• Ordinary app source declares a provider and a caller account requirement. An app cannot create or override host client definitions or widen where managed credentials go. Individual people grant and retain their own accounts.
• The E2E setting stays test-only. A real-server scenario covers startup validation and an operator-owned OAuth flow, including refusal of a mismatched issuer, wider scopes and foreign credential hosts.

These provider-specific PRs illustrate the need, rather than a request to add each deployment's clients to Executor's built-in list:

• fix: retain OAuth redirect URI on refresh #2366 (GitLab and Miro)
• feat: offer hosted Atlassian OAuth client #2367 (Atlassian)
• feat: require declared nested OAuth grants on exchange #2371 (Slack Web API)
• feat: add Zoho CRM regional OAuth clients #2373 (Zoho)
• feat: add hosted Zendesk OAuth client #2376 (Zendesk)

The per-provider definitions belong to the deployment that operates those OAuth clients. Generic SDK exchange behavior from those PRs can be contributed separately. Please advise the preferred configuration API and compatibility constraints for this shared host capability.