bug(mcp): uteke-mcp ignores [embedding] and [vector] of uteke.toml and UTEKE_EMBEDDING_* (always ONNX) #1535

Problem

uteke-mcp opens the store with Uteke::open(path), which uses the built-in embedding backend (onnx), default embedding settings and no vector-engine preference. It reads none of: [embedding] (backend, model, api_key, base_url, endpoint_path, dims, max_seq_length) and [vector] backend from uteke.toml, nor UTEKE_EMBEDDING_BACKEND. The backend variable is resolved by the CLI (apply_env_overrides) and by uteke-serve (resolve_embedding), not by the core, so the MCP binary can never select a backend other than onnx. The core does read UTEKE_EMBEDDING_MODEL, _BASE_URL, _ENDPOINT_PATH, _API_KEY and _DIMS (and UTEKE_VECTOR_BACKEND), but only the openai and ollama backends use them, and MCP cannot select those, so for MCP they have no effect.

So the same store is written with a different embedder over MCP than over the CLI or the server once a user configures anything but ONNX, and the MCP side does it silently.

Evidence (binaries built from develop at 2026-10-22, real ONNX model in a throwaway UTEKE_HOME)

Config: [embedding] backend = "ollama", base_url = "http://127.0.0.1:1" (nothing listens there), or the same through UTEKE_EMBEDDING_BACKEND=ollama UTEKE_EMBEDDING_BASE_URL=http://127.0.0.1:1.

Consequences

• A user who configured openai or ollama (or a custom dims) gets vectors from a different model written into the same index by MCP, or a dimension mismatch when the dimensions differ. Recall quality degrades or the vector write fails, and nothing says why.
• The vector-engine preference ([vector] backend) is ignored too (UTEKE_VECTOR_BACKEND is honoured).
• MCP over HTTP (POST /mcp on uteke-serve) is not affected: it runs inside the server, which opens the store from its own resolved settings.

Direction

Resolve the embedding backend, settings and vector preference in one place (the core, next to EngineSettings from #1515) and use it from the CLI, the server and MCP; the MCP binary then opens with open_with_embedding_and_graph like the others. Both existing resolvers (CLI apply_env_overrides, server resolve_embedding) have the same precedence rules, so the move should not change them; keep their tests.

Behaviour impact

MCP changes for users who configured a non-ONNX backend: it starts honouring it (and surfaces an unreachable backend as a warning instead of silently using ONNX). CORE note for uteke-cloud before merging (same as #1515 part 4).

Acceptance

• uteke-mcp honours [embedding], [vector] and the UTEKE_EMBEDDING_* variables with the same precedence as the CLI and the server (test with an unreachable backend: warning, not a silent ONNX write).
• One resolver for the three binaries (no copy of the env precedence).
• Side-by-side run of the old and new binaries on the same config, as for refactor: apply engine configuration in one place (the MCP binary applies none) #1515.

Found while reviewing #1515 part 4 (#1533). Related: #1355, #1515, #1523.