Would like to take this. Plan, conservative scope — just the descriptor wiring, no new env-templating machinery:

Add src/integrations/vendors/cloudflare.ts modeled on xiaomi-mimo.ts / moonshot.ts. OpenAI-compatible classification.
Default base URL https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/ai/v1 — <ACCOUNT_ID> is a literal placeholder. Same shape advanced-setup.md already uses for Azure (https://your-resource.openai.azure.com/...). Users substitute via /provider baseUrl edit (matches how account-scoped Azure endpoints are documented today).
CLOUDFLARE_API_TOKEN env var; falls back to OPENAI_API_KEY.
Static catalog with the current default Workers AI chat models (@cf/meta/llama-3.3-70b-instruct-fp8-fast, @cf/meta/llama-3.1-8b-instruct, @cf/deepseek-ai/deepseek-r1-distill-qwen-32b, @cf/qwen/qwen2.5-coder-32b-instruct). Easy to switch to source: 'hybrid' later if you'd prefer dynamic discovery — Groq's mapModel pattern from feat(groq): dynamic model discovery with mapModel filtering and hybrid catalog #1143 works the same way against Cloudflare's /models endpoint.
Validation routing on api.cloudflare.com host so an environment-pasted URL maps back to this preset.
Regenerate integrationArtifacts.generated.ts via bun run scripts/generate-integrations-artifacts.ts.
README providers row + advanced-setup.md section.
Provider preset test + providerProfiles env-build test mirroring the MiMo / Venice coverage.

Out of scope for this PR (clean follow-ups):

Dedicated AI Gateway integration with gateway_id templating in the URL. Today users can already paste a full Gateway URL into OPENAI_BASE_URL; first-class support is a separate UX decision.
Dynamic model discovery from /models (Groq-style hybrid catalog).

PR within a few hours.

Add Cloudflare AI #1100

Description