Connector Approvals: stop blaming core's key check on the provider or Gutenberg - #1070

What?

Closes #1069

Stops Connector Approvals from blocking core's connector key check by attributing it to the provider plugin or to Gutenberg, which makes Settings → Connectors reject valid keys.

Why?

Core validates a key by listing the provider's models, and Caller_Identifier attributes each request to the outermost plugin on the stack. Two cases blame a plugin for what is really core's check (details and stack in #1069):

1. Provider blamed for its own key. When the provider's own class sends the request (the OpenRouter provider overrides sendListModelsRequest()), it is the only plugin on the stack. Providers that inherit the request from core's OpenAI-compatible base class are unaffected.
2. Gutenberg blamed. Gutenberg 23.9 through 24.0 validates keys in its polyfill of core's connectors.php, which the skip list does not cover.

#595 aimed to let core's credential checks and requests that only pass through a provider go through without approval. These are the two gaps left.

How?

• Http_Guard resolves the plugin that registered the connector's AI Client provider (AiClient::defaultRegistry()->getProviderClassName(), then the class file's plugin directory) and passes its slug to Caller_Identifier::identify().

• Caller_Identifier::identify() / resolve() accept those slugs and skip the matching plugin frames the same way core frames are skipped. If nothing else is on the stack, the caller is null and the request passes, the guard's existing rule for core-originated requests. A plugin calling through the provider is still identified; test_identifies_consumer_calling_through_an_infrastructure_plugin pins that.

  I did not use "the connector's owner is always approved": a consumer hooked inside the provider's code would be attributed to the provider and let through that way.

• Skip list gains gutenberg/lib/compat/wordpress-7.0/default-connectors.php, next to core's connectors.php. Gutenberg 24.1 RC no longer ships that file, so the entry becomes inert once sites upgrade.

• The identifier's per-request cache key now includes the slugs.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5.5
Used for: investigating the root cause, writing the fix, the tests and this description, under my direction.

Testing Instructions

Unit tests

npm run test:php -- --filter Caller_IdentifierTest

The three new tests are test_skips_infrastructure_plugin_frames_when_core_validates_a_key, test_skips_gutenberg_connectors_polyfill and test_identifies_consumer_calling_through_an_infrastructure_plugin. On develop the first two fail; the third passes on both and guards against exempting too much. The whole Connector_Approval folder passes (30 tests), and phpcs and PHPStan are clean.

Manual

1. Activate the OpenRouter provider (ai-provider-for-openrouter from wordpress.org) and enable Connector Approvals. Keep Gutenberg inactive.
2. Save any key in Settings → Connectors → OpenRouter.
3. On develop: "It was not possible to connect to the provider using this key." and a pending ai-provider-for-openrouter request. On this branch: the key saves and nothing is pending. (OpenRouter's /models does not authenticate, so any key string passes the check once the request goes out.)
4. With Gutenberg 24.0 or earlier active, develop records the pending request for gutenberg/gutenberg.php; this branch saves the key.

Saving an OpenRouter key through POST /wp/v2/settings on a clean site (AI plugin, OpenRouter provider 1.0.0, Connector Approvals on):

The same check for ai-provider-for-openai is allowed on both, since its request comes from core's base class.

Changelog Entry

Fixed - Connector Approvals no longer blocks core's connector key check by attributing it to the provider plugin or to Gutenberg.