Healthcheck observability: providers.neoEmbedding (SQLite-side, symmetric to providers.embedding)

Context

Follow-up to PR #10767 (feat(memory-core): surface active embedding provider in healthcheck (#10723)). Surfaced in @neo-gemini-3-1-pro's review (commentId IC_kwDODSospM8AAAABBTBnRg) as a non-blocking architectural observation.

PR #10767 surfaces aiConfig.chromaEmbeddingProvider state under providers.embedding. The Memory Core also has a SQLite-side embedding path controlled by aiConfig.neoEmbeddingProvider (env var NEO_EMBEDDING_PROVIDER), used for native-edge-graph operations on the SQLite engine. Currently the healthcheck does NOT surface the SQLite-side provider state.

The Problem

Operators can intentionally diverge NEO_EMBEDDING_PROVIDER from NEO_CHROMA_EMBEDDING_PROVIDER (different providers for different storage engines). When this happens:

• A misconfigured NEO_EMBEDDING_PROVIDER (e.g. unset → silent default to gemini, while operator believes a local provider is wired) is undetectable from the healthcheck surface.
• Operators have no way to verify which SQLite-side provider was actually selected at boot.
• Even when both providers SHOULD match (most shared deployments), operators can't confirm the match without inspecting logs / re-running config through node -e.

The PR #10767 docs already note this asymmetry in SharedDeployment.md ("A sibling override NEO_EMBEDDING_PROVIDER controls the SQLite-side embedding path; in most shared deployments it should match NEO_CHROMA_EMBEDDING_PROVIDER for consistency, but it can diverge when the SQLite and ChromaDB engines use different providers intentionally") — but doesn't surface it in healthcheck.

The Architectural Reality

• ai/mcp/server/memory-core/services/HealthService.mjs#buildEmbeddingProviderBlock (added in PR #10767) — currently reads cfg.chromaEmbeddingProvider only
• aiConfig.neoEmbeddingProvider — the SQLite-side provider config (parallel field to chromaEmbeddingProvider)
• learn/agentos/SharedDeployment.md "Healthcheck Verification" — currently documents providers.embedding shape with single-provider field

The Fix

Two equivalent shapes worth considering:

Option A (parallel, structurally explicit): add a sibling providers.neoEmbedding block:

"providers": {
    "embedding": { "active": "...", "host": "...", "model": "...", "dimensions": ... },
    "neoEmbedding": { "active": "...", "host": "...", "model": "...", "dimensions": ... }
}

Option B (single block with chroma + neo subfields): restructure providers.embedding to surface both:

"providers": {
    "embedding": {
        "chroma": { "active": "...", "host": "...", "model": "...", "dimensions": ... },
        "neo":    { "active": "...", "host": "...", "model": "...", "dimensions": ... }
    }
}

Option B is cleaner conceptually (both are embedding providers, just for different engines). Option A is closer to the current shape (less restructuring; backward-compatible if any consumer already reads providers.embedding).

Recommendation: Option B (clean restructure now while consumers are still few — only this session's #10770 follow-up references the shape; no public API consumers yet).

Acceptance Criteria

• buildEmbeddingProviderBlock (or successor function) reads BOTH chromaEmbeddingProvider AND neoEmbeddingProvider; healthcheck surfaces both
• Mismatch case (the two providers differ) is observable — operators can see at-a-glance whether the two are aligned
• Unit tests extended: cover same-provider + diverged-provider scenarios
• learn/agentos/SharedDeployment.md Healthcheck Verification subsection updated to show the new shape
• Backward-compatibility note in PR body if Option A is taken; restructure-justification if Option B

Contract Ledger (T3)

Per parent epic #10721 AC2 (Contract Completeness Gate). Matrix added 2026-05-06 in response to @neo-gpt's hand-back (suggested row encoded verbatim with editorial adjustments to pin the recommended option).

Out of Scope

• Provider-provider compatibility validation (e.g. dimensions match across both engines) — separate concern; this ticket is observability only
• Adding new provider types — this only surfaces existing config, not new functionality
• Healthcheck providers.auth (separate follow-up #10770)

Related

• Adjacent shipped: PR #10767 (the current providers.embedding block)
• Adjacent follow-up: #10770 (providers.auth healthcheck observability — sibling shape for the auth dimension)
• Pattern precedents: #10176 buildIdentityBlock, #10127 buildTopologyBlock, #10723 buildEmbeddingProviderBlock (chroma side)
• Parent epic: #10721 (Shared deployment MVP completeness gaps) — this is post-trial-readiness polish, not blocking trial

Origin Session ID: 23b9cbcd-4938-4a46-b21a-0d48dd12e7e7

Retrieval Hint: query_raw_memories(query="healthcheck providers neoEmbedding SQLite-side symmetric chromaEmbeddingProvider 10767 10723 observability sibling")