Connectors API: a documented connector type for AI services the AI Client does not drive

[juanml]

WP_Connector_Registry::register() documents one value for type, ai_provider, which is special-cased: the key is handed to the PHP AI Client and validated on save, and reset when validation fails (​https://github.com/WordPress/wordpress-develop/pull/13031 describes the re-validation). A non-generative AI service, one that returns probabilities and confidence rather than text, cannot pass that validation, so registering it as ai_provider would clear a working key.

https://core.trac.wordpress.org/ticket/64791 established that plugin-defined types are intended (its use cases include "add a non-AI connector"), and that works: registering under a type of one's own renders the card in its own group on Settings › Connectors, the key is stored and masked by core, and it resolves with the usual env/constant/option precedence. Two gaps remain:

1. The register() docblock still reads as if ai_provider were the vocabulary: @type string $type Required. The connector type, e.g. 'ai_provider'. Nothing states that other values are supported or how the Connectors screen treats them.

2. An AI service outside the AI Client is neither ai_provider nor a plain non-AI service, and there is no name for it. Each such plugin invents a type, and the screen groups by type, so two judgement-model connectors from two authors would land under two headings. A documented core value (ai_service, or whatever name fits) would let them group together, and would give the AI plugin something to recognise when it decides whether AI credentials exist.

Ask: document that plugin-defined types are supported, and add or name one for AI services the AI Client does not drive.

Working example: ​https://github.com/juanlentino/jev-connector, registered as ai_decision, verified on 7.1. Companion request on the PHP AI Client side, for a capability that would let such models be first-class there: ​https://github.com/WordPress/php-ai-client/issues/296.