Undocumented 1024-dim embedding floor fails asynchronously while /health still reports embed: true

Summary

[embedding] hard-requires vectors of at least 1024 dimensions, but this floor is undocumented and unvalidated at startup. A 768-dim provider is accepted everywhere it is checked, and only fails later, asynchronously, in the ingest cascade — while /health continues to report embed: true and ok.

The practical result is an index that silently contains nothing and a health endpoint that says it is fine.

Reproduce

Configure any 768-dim embedding provider — Ollama's nomic-embed-text is the obvious one, since it is the most common local default:

[embedding]
provider = "openai"          # Ollama's OpenAI-compatible endpoint
base_url = "http://127.0.0.1:11434/v1"
model    = "nomic-embed-text"

Then:

1. everos server start
2. GET /api/v2/health → {"embed": true, "status": "ok"} ← passes
3. POST /api/v2/memory/add → 202 Accepted ← accepted
4. The background cascade fails:

ValidationError: List should have at least 1024 items after validation, not 768

1. Rows are persisted with retryable=FALSE.
2. POST /api/v2/memory/search → zero results, HTTP 200.
3. GET /api/v2/health → still ok, still embed: true.

Why this is worth fixing

Every surface a user would check to answer "is my embedding provider working?" returns a positive answer:

• the health endpoint reports embed: true
• the write returns 202
• search returns 200, just with an empty result list

Nothing distinguishes "the corpus contains no match" from "nothing was ever indexed." Silent, non-retryable data loss with a green health check is a bad failure mode for a memory system specifically, because the symptom — recall that comes back empty — is indistinguishable from normal operation on a cold store.

Suggested fix

Any one of these would be enough; the first is the cheapest:

1. Validate at startup. Embed a probe string once when the provider is configured, compare len(vector) against _DEFAULT_DIM, and refuse to start (or log a hard error) on mismatch. This turns a silent async failure into a loud synchronous one.
2. Reflect it in /health. embed: true should mean "an embedding of the correct dimension was produced", not "a provider is configured".
3. Document the floor. At minimum, state the ≥1024 requirement next to the [embedding] config block, and name a couple of local models that satisfy it — this is not discoverable from the config reference today.

Workaround

Use a provider whose native dimension is ≥1024, or truncate client-side. For Ollama, qwen3-embedding:8b (4096-dim) works; nomic-embed-text (768) does not.

Environment

• everos 1.2.3, Python 3.12, Linux
• LanceDB backend, local Ollama for both LLM and embeddings
• Found while ingesting a 45-file Markdown corpus; 0 of the first batch became searchable before the dimension mismatch was identified