feat(embedding): add a provider-neutral LiteLLM embedding node #2065

Problem

embedding_openai declares six profiles with modelSource: "litellm", but
OpenAIEmbeddingWrapper never reads modelSource. It passes every selected
model directly to LangChain's OpenAIEmbeddings using the default OpenAI
endpoint and probes the model during startup.

The affected profiles are:

• text-embedding-004
• text-embedding-005
• text-embedding-3-small-inference
• text-embedding-ada-002-v2
• text-embedding-large-exp-03-07
• text-embedding-preview-0409

Selecting one sends a non-OpenAI model identifier to OpenAI, so startup fails
before the node processes documents or questions.

CodeRabbit found this while reviewing the regenerated README in #1975:
#1975 (comment)

The short-term documentation clarification is committed in #1975. It identifies
the three profiles that currently work and explains that the other six are not
routed.

Proposed direction

Create a provider-neutral embedding_litellm node instead of adding multiple
providers to embedding_openai.

Keep embedding_openai limited to direct OpenAI models. A separate LiteLLM
node makes the provider boundary, credentials, dependencies, model naming, and
failure behavior explicit.

Use LiteLLM's embedding API or a deliberately configured LiteLLM proxy. Do not
send LiteLLM profiles through OpenAIEmbeddings without an explicit compatible
endpoint.

Before moving any of the six profiles, verify that LiteLLM currently supports
the model and determine its canonical provider-prefixed identifier and required
credentials. The existing raw identifiers should not be assumed to be routable.

Acceptance criteria

• Add an embedding_litellm node with the same documents and questions
  lane contract as the existing text embedding nodes.
• Route document batches and single questions through LiteLLM's embedding
  surface or an explicitly configured LiteLLM proxy.
• Require provider-qualified model identifiers where LiteLLM requires them.
• Define secure, provider-appropriate credential and endpoint configuration;
  do not assume one OpenAI API key works for every provider.
• Probe vector size through the selected LiteLLM backend, not the OpenAI
  backend.
• Preserve the requirement that ingestion and querying use the same embedding
  model and vector dimensions.
• Audit all six affected profiles. Add only profiles proven to work through
  the selected route; remove or leave unsupported any model that cannot be
  verified.
• Keep embedding_openai with only direct OpenAI profiles after the migration.
• Add tests for profile routing, authentication selection, document batching,
  question embedding, startup probing, and clear provider errors.
• Add a README following docs/development/nodes/readme-schema.md and regenerate
  machine-owned parameter sections.
• Validate both nodes with scripts/validate-node-readme.py and relevant node
  tests.

Why a separate node

embedding_openai is provider-specific in its name, dependency, credential
model, and implementation. Teaching it to switch among unrelated providers
would make its contract misleading and create conditional authentication and
endpoint behavior inside an OpenAI node. embedding_litellm gives users an
explicit choice between direct OpenAI access and provider-neutral routing.