fix: centralize embedding model config to prevent query/ingest mismatch

[OmkarKirpan]

Summary

Closes #903

Adds centralized embedding model configuration so the MCP server, CLI search, and all ingest paths use the same model — fixing silent query failures when models mismatch.

Design Decisions

1. Storage approach: Embedding model name stored in ChromaDB collection metadata (not a separate file). Atomic with the collection, can't desync. Absence of the key = legacy palace.

2. Default for new palaces: all-mpnet-base-v2 (768-dim) — better search quality (+3.5pp on LoCoMo R@10 benchmarks over MiniLM).

3. Default for existing palaces: all-MiniLM-L6-v2 (384-dim) — backwards compatible, no re-mining required. Detected by absence of embedding_model key in collection metadata.

4. Resolution chain: Collection metadata (authoritative) > config file / env var (new palaces only) > built-in default. This means once a palace is created, its model is locked in and self-describing.

5. No migration tool in this PR: Re-embedding existing palaces from MiniLM to mpnet is a separate concern. This PR prevents the mismatch; migrating existing palaces is a follow-up.

6. All create paths stamp the model: Repair, rebuild, and migrate operations preserve the original model through the delete/recreate cycle.

Resolution chain

1. Collection metadata "embedding_model" key (authoritative, stamped at build)
2. If absent → legacy palace → all-MiniLM-L6-v2
3. config.json "embedding_model" or MEMPALACE_EMBEDDING_MODEL env var → new palace creation only

Files changed

• New: mempalace/embedding.py — model registry, resolution, embedding function factory
• Modified: mempalace/config.py — embedding_model property on MempalaceConfig
• Modified: mempalace/backends/chroma.py — get_collection(), get_or_create_collection(), create_collection() accept embedding_function + embedding_model_name
• Modified: mempalace/palace.py — resolves model from metadata on read, stamps on create
• Modified: mempalace/mcp_server.py — _get_collection() uses correct embedding function, tool_status() reports active model
• Modified: mempalace/cli.py, mempalace/repair.py, mempalace/migrate.py — all collection-create paths now stamp embedding model

Known follow-ups (not in scope)

• Performance: double get_collection call on read paths for metadata resolution (~ms overhead, within budget)
• Migration tool to re-embed existing MiniLM palaces with mpnet
• OpenAI/external embedding support (Add MemPalace OpenAI 3072-dim embedding support or something similar opensource. #756)
• GPU acceleration (feat: GPU-accelerated embeddings via optional sentence-transformers #515)

Test plan

• 936/936 tests pass locally
• Legacy palace (no metadata key) resolves to MiniLM
• New palace creation stamps mpnet in collection metadata
• Config override and env var override work
• Repair/migrate preserve embedding model through rebuild
• mempalace_status reports active embedding model
• ruff check and ruff format clean

[NickShtefan]

@OmkarKirpan — heads-up that #442 just got rebased onto develop (mergeStateStatus moved from DIRTY → UNSTABLE; CI running). My fixes overlap on the _get_collection mismatch bug (#903) but the scopes differ:

	#912	#442
MCP _get_collection reads model from collection metadata	✓	✓
EmbeddingModelMismatchError	—	✓ (raised + propagated through handle_request)
mempalace init --model <name>	—	✓ (model stamped at palace creation)
mempalace re-mine --model <new>	—	✓ (safe migration)
Auto-detect device (cuda > mps > cpu)	—	✓
[multilingual] extra	—	✓
Default for new palaces	mpnet-base-v2 (768)	configurable via --model
Backwards compat for legacy palaces	✓ (MiniLM fallback)	✓ (auto-stamped as chromadb-default)

#442 effectively contains your fix as a subset. If maintainers prefer the broader scope, #912 would be superseded. If they prefer the narrower minimal fix first, I can wait for #912 to merge and rebase #442 on top — happy to coordinate either way.

@igorls @bensig — would appreciate guidance on which sequencing you want.