store.js DEFAULT_EMBED_MODEL label ignores QMD_EMBED_MODEL env var

[Hakku]

Bug

store.js exports DEFAULT_EMBED_MODEL = "embeddinggemma" (line 24), which is used as the model metadata written to the content_vectors table (line 877: options?.model ?? DEFAULT_EMBED_MODEL).

However, the actual model loaded for embedding is determined by llm.js line 51:

const DEFAULT_EMBED_MODEL = process.env.QMD_EMBED_MODEL ?? "hf:ggml-org/embeddinggemma-300M-GGUF/...";

These are two separate DEFAULT_EMBED_MODEL constants in different files with different semantics:

File	Value	Used for
llm.js:51	env var → fallback HF URI	Actual model loading (GGUF resolution)
store.js:24	"embeddinggemma" (hardcoded)	DB metadata label + display text

Impact

When QMD_EMBED_MODEL is set to a different model (e.g. hf:Qwen/Qwen3-Embedding-0.6B-GGUF/...):

1. The correct model loads and generates embeddings (verified: vec table is float[1024], matching Qwen3, not embeddinggemma's 256-dim)
2. But content_vectors.model stores "embeddinggemma" — misleading metadata
3. qmd embed progress output says "Model: embeddinggemma" regardless of actual model

This makes it hard to verify which model was actually used for stored embeddings.

Suggested fix

store.js:generateEmbeddings should derive the model label from the LlamaCpp instance's embedModelUri rather than the hardcoded DEFAULT_EMBED_MODEL string. Something like:

const llm = getLlm(store);
const model = options?.model ?? llm.embedModelUri ?? DEFAULT_EMBED_MODEL;

Environment

• qmd 2.0.1
• Windows 11, Node 24
• QMD_EMBED_MODEL=hf:Qwen/Qwen3-Embedding-0.6B-GGUF/Qwen3-Embedding-0.6B-Q8_0.gguf