Support client_secret_basic for OAuth client credentials #1447

Problem

Executor's low-level OAuth helper supports both client_secret_post and client_secret_basic, but configured OAuth clients do not persist or expose the token-endpoint authentication method. The service-level client-credentials mint and expiry re-mint therefore omit clientAuth and always use the default body transport.

This blocks authorization servers that require HTTP Basic client authentication at the token endpoint. A concrete example is Aikido:

POST https://app.aikido.dev/api/oauth/token
Authorization: Basic base64(CLIENT_ID:CLIENT_SECRET)
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

Executor currently sends client_id and client_secret in the form body instead, which Aikido rejects.

A previous broad implementation in #1217 included a per-client token_endpoint_auth_method and covered initial mint plus expiry re-mint, but that PR was closed unmerged.

Expected behavior

• OAuth clients can select client_secret_basic or client_secret_post.
• The selection is persisted.
• Both the initial client_credentials exchange and subsequent expiry re-mints use the selected method.
• Existing clients remain compatible by defaulting to client_secret_post.
• The configuration UI/API exposes the choice, ideally using the standard OAuth names.

References

• RFC 6749 §2.3.1: https://www.rfc-editor.org/rfc/rfc6749.html#section-2.3.1
• Aikido token endpoint: https://apidocs.aikido.dev/reference/getaccesstoken
• Prior closed implementation: Add OAuth2 client_credentials auth for MCP and GraphQL integrations #1217