feat: implement native Ollama embedding provider

[PatrickSys]

Background

Right now there's a placeholder in the embedding provider code that falls back to Transformers.js when Ollama is selected:

if (mergedConfig.provider === 'ollama') {
    console.warn('Ollama provider not yet implemented, falling back to Transformers.js');
}

This means setting EMBEDDING_PROVIDER=ollama does nothing useful — you still end up running local Transformers.js inference, which defeats the point.

Why this matters

Ollama is the most common way people run local models. Having real Ollama support would mean:

• No native binary crashes — sidesteps the onnxruntime-node mutex bug on macOS (see Bug Report: Mutex Lock Failed During Indexing on Intel Mac #68) entirely, without needing an OpenAI API key
• Private, offline embeddings — code never leaves the machine
• Model flexibility — users can pick whatever embedding model they've pulled locally (e.g. nomic-embed-text, mxbai-embed-large)
• Free — no API costs

What the implementation would look like

Ollama exposes an OpenAI-compatible embeddings endpoint at /api/embed (and /v1/embeddings for the OpenAI-compat layer). The simplest path is probably a thin provider class similar to the existing OpenAIEmbeddingProvider, pointing at http://localhost:11434 by default and reading the host from an env var (e.g. OLLAMA_HOST).

EMBEDDING_PROVIDER=ollama
OLLAMA_HOST=http://localhost:11434   # optional, this would be the default
EMBEDDING_MODEL=nomic-embed-text

The main things to figure out:

• Which Ollama API endpoint to use (/api/embed vs /v1/embeddings)
• How to handle dimension detection (model-dependent, could query /api/show)
• Whether to require the user to have the model already pulled, or surface a clear error

Related

• Bug Report: Mutex Lock Failed During Indexing on Intel Mac #68 — mutex crash on macOS when using Transformers.js; Ollama would be a clean local alternative
• Feature Request: Support custom OpenAI-compatible API endpoints (OPENAI_BASE_URL) #70 — adds OPENAI_BASE_URL support, which technically lets you point at Ollama's OpenAI-compat layer as a short-term workaround, but native support would be cleaner