Connectors: don't clobber third-party custom render in registerDefaultConnectors

[superdav42]

What

registerDefaultConnectors() in routes/connectors-home/default-connectors.tsx was unconditionally setting args.render = ApiKeyConnector for any api_key-authenticated connector, overwriting custom renders that third-party plugin script modules had already supplied via __experimentalRegisterConnector().

This PR makes the assignment conditional on no existing render being registered, so plugin-supplied renders survive while the rest of the server-side metadata (logo, plugin install state, authentication config) still merges on top.

Why

registerDefaultConnectors() runs inside the dynamically-imported routes/connectors-home/content module. By the time it runs, every top-level plugin script module — including any that enqueued on the standard options-connectors-wp-admin_init action — has already executed and registered its connectors. The store reducer spreads new config over existing entries:

[ action.slug ]: {
    ...state.connectors[ action.slug ],   // existing
    slug: action.slug,
    ...action.config,                      // new (wins per key)
}

So whichever caller fires last wins per key, and registerDefaultConnectors() is always last for plugins that enqueue at the standard hook. The result is that any plugin shipping a custom Connectors-page card sees it silently replaced by the generic ApiKeyConnector API-key form.

This is particularly painful for local/self-hosted AI providers (Ollama, LM Studio, WebLLM, etc.) that don't have an API-key concept at all — the rendered form is meaningless and confusing for users.

PR #76722 added JS-extensibility e2e coverage but only for the server-then-client direction (where the test plugin's connector uses auth: 'none', so the clobber path is never hit). The client-then-server direction for auth: 'api_key' connectors was unverified and broken — see issue #77115 for the full root-cause walkthrough and a live reproducer plugin.

How

In default-connectors.tsx, before deciding whether to assign the default ApiKeyConnector render, read the current entry from the connectors store via the same unlock( connectorsPrivateApis ) pattern stage.tsx already uses:

const existing =
    unlock( select( connectorsStore ) ).getConnector( connectorName );
if ( authentication.method === 'api_key' && ! existing?.render ) {
    args.render = ApiKeyConnector;
}

When args.render is omitted, the reducer's spread of the existing entry preserves whatever render the plugin already registered. Server-side metadata (name, description, logo, authentication, plugin) still merges on top of the existing entry as before.

Test plan

Adds a third connector test_api_key_with_custom_render to the connectors-js-extensibility test plugin:

• PHP (packages/e2e-tests/plugins/connectors-js-extensibility.php): registers test_api_key_with_custom_render with type: 'ai_provider' and authentication.method: 'api_key' — exactly the path that hits the clobber.
• JS (packages/e2e-tests/plugins/connectors-js-extensibility/index.mjs): calls registerConnector( 'test_api_key_with_custom_render', { render: ... } ) for it. This is what registerDefaultConnectors() would have overwritten without the fix.
• Spec (test/e2e/specs/admin/connectors.spec.js): a new test inside the JS extensibility describe block:
  • Asserts the custom render's text content ('Custom render survived registerDefaultConnectors().') is visible inside the expected card.
  • Asserts the card has zero API Key labels — i.e. the default ApiKeyConnector form is absent.

This explicitly exercises the previously-uncovered direction. Without the source fix, the new spec fails (the card shows the API Key form instead of the custom content).

• Existing JS extensibility tests still pass.
• New should preserve a custom render for an api_key connector... test passes.
• Manual smoke: install any third-party AI provider plugin that registers a custom connector card (e.g. https://github.com/Ultimate-Multisite/ultimate-ai-connector-webllm) and verify the custom card renders without needing the multi-tick registerConnector workaround.

Closes #77115.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: superdav42 <superdav42@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @superdav42! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[superdav42]

I don't have permission to apply labels — could a maintainer add [Type] Bug so the required-labels check passes? Thanks!