[onatozmenn]

This is a small first slice for #4756, mostly to check the shape before touching runtime behavior.

What it does:

• Adds api_flavor to the provider catalog: openai, openai-compatible, or gateway.
• Classifies the current openai_vendor: true providers (openai, chatgpt, azure) as openai.
• Adds mistral as openai-compatible and openrouter as gateway as representative examples.
• Adds tests for the classification and an invariant that any openai_vendor: true provider must be api_flavor: openai.

What it intentionally does not do:

• It does not change openai_vendor or any runtime behavior yet.
• It does not classify every provider. Once the direction is agreed, the remaining catalog entries and the behavior gates can move over.

The idea is to keep api_type as the transport/client and use api_flavor for the semantic distinction, so a gateway or a compatible provider is not mistaken for a first-party OpenAI endpoint. Happy to adjust the naming or drop this if you would rather go a different way.

Follow-up to #4755. Refs #4756.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[onatozmenn]

Hey @rumpl, quick ping on this one. I rebased it on main and the catalog tests pass locally. CI is still waiting for approval. No rush at all, just checking if the api_flavor direction is what you had in mind before I take it further. Happy to rename things or close it if not.

[aheritier]

The classification matches this metadata-only slice of #4756 without changing runtime behavior. Tests cover all five classified providers, allowed flavor values, and the OpenAI-vendor invariant. No findings.

[rumpl]

Update, didn't have the time yet to look at this one, will try today