## Check for existing issues - [x] I have searched the existing issues and checked that my issue is not a duplicate. (Closest is #26443, but that concerns the *chat* path — a provider-specific param bypassing `extra_body`. This report is a different, embeddings-only routing bug.)

## What happened?

Calling `litellm.embedding()` / `litellm.aembedding()` with a Scaleway model fails immediately with `LiteLLMUnknownProvider`, **before any network call is made**. Scaleway **chat completions work fine** — only the embeddings endpoint is affected, even though Scaleway offers OpenAI-compatible embedding models (`qwen3-embedding-8b`, `bge-multilingual-gemma2`) on the same `https://api.scaleway.ai/v1` base URL.

**Expected:** the request is routed to the OpenAI-compatible embedding handler and returns an embedding vector, exactly as chat completions already do for Scaleway.

**Actual:** `LiteLLMUnknownProvider` is raised before any HTTP request.

### Root cause

There is an asymmetry between `completion()` and `embedding()` in how JSON-configured providers are routed.

`scaleway` is a JSON-configured provider (`litellm/llms/openai_like/providers.json`), correctly registered as an OpenAI-c…