bug: Cerebras and Groq silently drop vision images — no supportsVision declaration, no error thrown

[stackbilt-admin]

Bug

Requests that include images in the message payload are silently accepted by Cerebras and Groq, but the images are never forwarded to the provider API. The response is generated from text only, with no indication that the images were ignored.

Locations:

• src/providers/cerebras.ts — no supportsVision property on the class (should be supportsVision = false)
• src/providers/groq.ts — same

Neither provider implements image formatting in formatRequest / formatMessageContent. Because supportsVision is absent (evaluates falsy), the factory does not exclude these providers from the fallback chain when a vision request arrives.

Contrast with Cloudflare

src/providers/cloudflare.ts:469–473 correctly throws a ConfigurationError when a model without supportsVision capability receives image inputs. Cerebras and Groq need equivalent protection.

Impact

A caller that sends a vision request and happens to be routed to Cerebras or Groq receives a degraded, text-only response with no error. The call succeeds (HTTP 200), masking the data loss entirely.

Fix

1. Add supportsVision = false to both CerebrasProvider and GroqProvider
2. In LLMProviderFactory.buildProviderPlan(), filter providers by supportsVision when request.images?.length > 0, or throw ConfigurationError before the request is dispatched — matching the Cloudflare pattern

Acceptance criteria

• CerebrasProvider.supportsVision === false and GroqProvider.supportsVision === false are declared
• Sending images to either provider throws ConfigurationError rather than silently discarding them
• Factory fallback correctly skips vision-incapable providers when images are present
• Tests added for vision request routing with Cerebras/Groq in the chain

Found by

Codebase audit (automated) — independently flagged by provider-parity and vision-handling audit slices