Remove unnecessary AiClient::isConfigured() wrapper method

[Ref34t]

The AiClient::isConfigured() method just calls $availability->isConfigured() with no added value.

As noted by @JasonTheAdams in PR #55 - why not just have ProviderInterface::isConfigured() directly?

@felixarntz suggested logging this issue to revisit the pattern after core functionality is complete.

Current:

AiClient::isConfigured($availability)  // wrapper

Proposed:

$provider->isConfigured()  // direct call

This removes unnecessary abstraction and simplifies the API.

[felixarntz]

I think there may be a misunderstanding - removing the AiClient method should definitely not happen because calling $provider->isConfigured() directly would mean we don't centrally control wiring up the dependencies (like the HttpTransporter instance).

I think the main concern was that calling

AiClient::isConfigured(Google::availability())

is too verbose, and that calling

AiClient::isConfigured('google')

or calling

AiClient::isConfigured(Google::class)

would be more straightforward.

I am inclined to say we could simply allow all three - they're all valid ways to get the same information. In the first example, the developer passes the ProviderAvailabilityInterface directly - in the second and third example the developer passes the $providerIdOrClassName, and then AiClient can get the ProviderAvailabilityInterface itself from the registry.

Does this work for you @Ref34t @JasonTheAdams?

[Ref34t]

After analyzing the codebase, I agree with @felixarntz that removing the wrapper would break centralized dependency management. The ProviderRegistry automatically injects HttpTransporter instances into availability objects.

Instead of removal, let's enhance AiClient::isConfigured() to support the flexible patterns Felix suggested:

// Current (still works)
AiClient::isConfigured($availability)

// Enhanced - leverages registry's dependency  injection  
AiClient::isConfigured('openai')              // By  ID  
AiClient::isConfigured(OpenAiProvider::class) // By class

This maintains backward compatibility while adding real value through centralized configuration management.

The ProviderRegistry already has isProviderConfigured() that handles ID/class resolution - we just need to expose this through the AiClient API.

Would you like me to prepare a PR implementing this enhancement?

[felixarntz]

@Ref34t That would be great - thank you!