AI: Return false from support checks when the wrapped builder throws

[jigneshbhavani]

WP_AI_Client_Prompt_Builder::__call() catches an exception from the wrapped SDK builder, stores it as the error state, and then only special cases the generating methods:

} catch ( Exception $e ) {
	$this->error = $this->exception_to_wp_error( $e );

	if ( self::is_generating_method( $name ) ) {
		return $this->error;
	}
	return $this;
}

is_supported() and the seven is_supported_for_*() methods are not generating methods, so they fall through to the fluent return and give back the builder instance. It is truthy, so a support check that failed reads as a success:

if ( wp_ai_client_prompt( 'Write a haiku' )->is_supported() ) {
	// Runs even though the support check could not be completed.
}

Everywhere else in the class this is handled. The error state guard at the top of __call() returns false for support checks, and so does the prevented prompt path. Only an exception raised during the support check itself takes the wrong branch.

Reproducing it

ModalityEnum::document() is a documented factory, but PromptBuilder::inferCapabilityFromOutputModalities() has no branch for it and throws a RuntimeException in its else. That call is outside the try block isSupported() uses to swallow InvalidArgumentException, so it reaches the wrapper.

$result = wp_ai_client_prompt( 'Test text' )
	->as_output_modalities( ModalityEnum::document() )
	->is_supported();

var_dump( $result ); // object(WP_AI_Client_Prompt_Builder), expected bool(false)

Any throw from the wrapped builder during a support check behaves the same way. The document modality is just the shortest route to one.

Fix

Return false for support check methods from the catch block, so they match what they already return when the builder was in an error state beforehand. The error is still stored, so a later generating call still gets the WP_Error, and the test covers that.

Not a duplicate of #65505

#65505 is about the catch missing Error. Its patch widens catch ( Exception ) to catch ( Throwable ) and leaves the return logic untouched, so a support check still comes back as the builder after it lands. The two changes are independent and touch different lines.

Testing

test_support_check_methods_return_false_when_builder_throws() fails on trunk with:

Failed asserting that WP_AI_Client_Prompt_Builder Object (... 'error' => WP_Error ...
  'Output modality "document" is not yet supported.') is of type "bool".

and passes with the patch. The full ai-client group is green, 258 tests. phpcs passes on both changed files.

Trac ticket: https://core.trac.wordpress.org/ticket/65781

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Reading through the AI client for places where the code disagrees with its own documented behaviour, which is how this turned up, and drafting this description. I confirmed the throw path in the bundled client myself, wrote and ran the test, checked it fails without the patch, ran phpcs, and I take responsibility for the change.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props bejignesh.

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

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.