Local embedding provider validation

Context

As part of the Shared Deployment MVP completeness gaps (post-#10691), we must ensure our abstraction layers work with real-world local models, specifically the Qwen3-1.8b embedding model.

The Problem

The current OpenAiCompatible abstraction exists but the specific path for the Qwen3-1.8b embedding model (at 4k dimensions) is unvalidated. We cannot confidently deploy the MVP for teams using this local model until it is empirically validated and properly documented.

The Architectural Reality

• OpenAiCompatible.generate provides the abstraction.
• The VectorService handles embeddings.
• Operator config paths need to clearly indicate how to swap the embedding provider.
• MemoryCore.md §Healthcheck Response Shape defines per-server topology diagnostics.

The Fix

Empirically validate the OpenAiCompatible abstraction against the Qwen3-1.8b embedding model (4k dimensions). Document the operator config path. Surface healthcheck verification of the active embedding provider. Flag any interface gaps the abstraction reveals.

Contract Ledger Matrix

Acceptance Criteria

• Empirically validate Qwen3-1.8b embedding model via OpenAiCompatible.
• Document the operator configuration path in SharedDeployment.md.
• Extend healthcheck to surface the active embedding provider.
• Flag and document (or fix) any abstraction interface gaps discovered during validation.

Out of Scope

• Adding support for entirely new protocol formats outside OpenAI-compatible endpoints.
• End-to-end performance benchmarking under team load.

Avoided Traps

• Rejected: Creating a bespoke Qwen provider class. The OpenAiCompatible abstraction is designed precisely to prevent provider proliferation. We must validate and harden the generic abstraction rather than writing custom wrappers.

Related

• Parent Epic: #10721
• Predecessor: #10691

Origin Session ID: 79042442-bebc-431d-8968-8a2e7d7a1151 Retrieval Hint: query_raw_memories(query="Local embedding provider validation Qwen3 4k OpenAiCompatible")