This PR implements RFC #402 by introducing a ProviderFactory and ProviderConfigFactory
to centralize the creation of AI provider platforms (OpenAI, Azure OpenAI, Azure Meta) from DSNs.

What’s new

• ProviderConfigFactory::fromDsn()
  Parses DSNs into a strongly typed ProviderConfig (provider, baseUri, apiKey, options, headers).
  Supports Azure family selection via engine (e.g. openai, meta) and common options like deployment, version, timeout, proxy, verify_peer, as well as headers[...].

• ProviderFactory::fromDsn()
  Instantiates the correct bridge PlatformFactory (OpenAi, Azure\OpenAi, Azure\Meta) using the parsed config.
  Sets proper authentication headers per provider (Authorization: Bearer … or api-key for Azure), and propagates base_uri, options, and headers to the bridge.

• Unit tests (positive & negative)
  Test coverage for both factories, including edge-cases for DSN parsing (e.g. no host → defaults, Azure validation).
  A dedicated PHPUnit configuration phpunit.provider-factory.xml runs tests that depend on fake bridge factories (see rationale below).
  A standard suite continues to run with the default phpunit.xml(.dist) without interference.

• Changelog
  Entry added in src/platform/CHANGELOG.md.

Why

This provides a unified, extensible mechanism to construct provider platforms from DSNs.
It makes configuration easier, allows future providers to be added consistently,
and aligns with the design goals outlined in RFC #402.

Why a dedicated PHPUnit config for some tests?

The existing bridges expose static factory methods (e.g. Bridge\*\PlatformFactory::create(...)).
Static factories are not mock-friendly: traditional PHPUnit doubles cannot intercept static calls and signatures differ per bridge.
To test ProviderFactory::fromDsn() deterministically without coupling the suite to real providers, we load fake bridge factories under the same FQCN via a bootstrap that prepends a PSR-4 mapping for the Bridge\ namespace.

• The special suite (phpunit.provider-factory.xml) uses tests/bootstrap_fake_bridges.php to ensure fake classes are loaded before the real ones.
• The main suite keeps using the default bootstrap, so real bridge tests remain untouched.
• These special tests are grouped (e.g. @group pf) and excluded from the main suite to avoid accidental mixing.

This split lets us:

• keep real bridge tests pristine,
• test the orchestration logic in ProviderFactory in isolation,
• avoid reflective heuristics around static method signatures.

Proposed follow-up Improvement (separate PR/RFC)

To remove the need for a separate PHPUnit config and fakes in the future, I propose introducing a thin, optional abstraction layer:

1. BridgePlatformFactoryInterface (small contract)

   interface BridgePlatformFactoryInterface {
       public function create(string $apiKey, HttpClientInterface $http, array $contract): object;
       public static function providerKey(): string;   // e.g. "openai", "azure"
       public static function engine(): ?string;       // e.g. "openai" | "meta" for Azure, null otherwise
   }

Adapters per existing bridge would simply delegate to the current static PlatformFactory::create(...).

2. BridgeFactoryResolverInterface + default implementation
   A registry that maps (providerKey, engine) → the corresponding adapter (injected via DI).
   ProviderFactory::fromDsn() would ask the resolver for the correct adapter, then call ->create(...).