Use canonical dummyEmbeddingFunction in defrag; drop github-workflow copy

Context

After PR #12164 (Epic #12101 Stage 1) merged and the orchestrator was rebooted (2026-05-29), operator review surfaced that the ChromaDB "dummy embedding function" — used to bypass server-side embedding generation when Neo provides embeddings directly — is defined in multiple divergent places instead of a single Tier-1 source. The unified Chroma topology (Memory Core + Knowledge Base share one instance) makes the EF realm-wide: it belongs once at Tier-1.

The Problem

Four divergent / misplaced definitions of the same dummy EF:

1. Tier-1 ai/config.template.mjs:612 — dummyEmbeddingFunction (name: 'dummy_embedding_function', verbose anti-legacy structure: name / getConfig / constructor.buildFromConfig).
2. Knowledge Base ai/mcp/server/knowledge-base/config.template.mjs:114 — re-declares its own copy.
3. defrag ai/scripts/maintenance/defragChromaDB.mjs:378-383 — hardcodes a third variant with name: 'dummy'. That literal 'dummy' is what chromadb 3.x maps to the (non-existent) @chroma-core/dummy package, producing the Collection schema deserialization … @chroma-core/dummy is not installed warning seen during chroma defrag (knowledge-base).
4. GitHub Workflow ai/mcp/server/github-workflow/config.template.mjs:84 — includes dummyEmbeddingFunction but never imports chromadb (V-B-A 2026-05-29: grep -c chromadb = 0). Dead config.

The Architectural Reality

• Unified Chroma (#11111 chroma-client primitives) — MC + KB share one Chroma instance; the dummy EF is a realm-wide constant, not a per-server concern.
• The canonical Tier-1 EF round-trips intact through the new reactive config (verified 2026-05-29: name, generate, getConfig, and the special own constructor.buildFromConfig all survive as callable functions).
• KB's ChromaManager reads aiConfig.dummyEmbeddingFunction; the defrag ignores config and hardcodes its own.

The Fix

1. Keep the single canonical dummyEmbeddingFunction leaf in Tier-1 ai/config.template.mjs (+ regenerated config.mjs).
2. KB: remove the duplicate definition; reference Tier-1's (default: AiConfig.dummyEmbeddingFunction snapshot now; becomes chain-inherited once the parent-chain realm-inheritance sub lands).
3. defrag defragChromaDB.mjs: import + use AiConfig.dummyEmbeddingFunction instead of the hardcoded name: 'dummy' object. The verbose canonical EF is expected to also clear the chromadb-3.x deserialization warning.
4. GH-workflow: delete dummyEmbeddingFunction (no chroma usage).

Contract Ledger

Acceptance Criteria

• dummyEmbeddingFunction defined exactly once (Tier-1); no independent object-literal definitions in server configs.
• KB config references Tier-1's EF (no independent literal).
• defragChromaDB.mjs uses AiConfig.dummyEmbeddingFunction; no hardcoded name: 'dummy'.
• GH-workflow config no longer contains dummyEmbeddingFunction.
• Verify whether the canonical EF clears the chromadb-3.x defrag warning; if residual, defer to the defrag warning-suppression follow-up tracked on #12102.

Out of Scope

• The Provider parent-chain wiring itself (the parent-chain realm-inheritance sub) — this ticket consolidates the definition; the chain makes KB inherit it rather than snapshot.
• chromadb-3.x warning suppression via createSilentExecutor in the defrag (tracked on #12102) — only relevant if the canonical EF doesn't already clear it.

Related

• Epic #12101; PR #12164 (merged Stage 1); #11111 (Chroma-client primitives — adjacent; #11111 deliberately did NOT share ensureDummyEmbedding at the wrapper layer, so this config-level SSOT is a distinct concern).

Origin Session ID: b124b83a-2cca-4a2b-a711-64868439ba1e Retrieval Hint: "dummyEmbeddingFunction single source of truth Tier-1 defrag chromadb"