Non-streaming chat calls should opt out of Fiber transport via ChatInput::setForceSynchronous(TRUE)

Problem/Motivation

AiSearchBlockHelper makes non-streaming chat calls that run inside a Fiber context. The Fiber branch in OpenAiBasedProviderClientBase::chat() activates for any call inside a Fiber, regardless of whether the caller requested streaming. This means a non-streaming call silently uses streamed API transport, which can break providers that do not support streaming correctly (e.g. some litellm and Groq configurations).

This was diagnosed and will be fixed in ai module: #3586457.

Proposed resolution

#3586457 adds ChatInput::setForceSynchronous(bool) as a per-request escape hatch (merged in ai MR !1646). When set to TRUE, the call always takes the synchronous path, even inside a Fiber.

The fix in AiSearchBlockHelper is a one-liner on the non-streaming path:

$input = new ChatInput($messages);
if (!$this->configuration['stream']) {
  $input->setForceSynchronous(TRUE);
}
$output = $provider->chat($input, $ai_model_to_use, ['ai_search_block']);

Remaining tasks

• Confirm ai MR !1646 is merged
• Add $input->setForceSynchronous(TRUE) on the non-streaming path in AiSearchBlockHelper
• Test with a provider that has a broken or unsupported streaming endpoint (e.g. litellm) to confirm the synchronous path is taken

User interface changes

None.

API changes

None. Uses the new ChatInput::setForceSynchronous() API introduced in #3586457.

Data model changes

None.