refactor(core): one way to ask for an embedding (lazy init, lock, retry, failure policy) #1538

Problem

Ten call sites reach the embedder (ensure_embedder() appears ten times) in four patterns:

• ensure_embedder + lock + .expect("embedder ensured above"): embed_text, doc_search_semantic, embed_document_chunks (two), room_ops room recall. Five expects, safe only because of call order.
• ensure + lock + error: recall_inner, recall_explain, maintenance reembed (holds the lock across its whole loop).
• retry_embed, error on failure: update, import.
• embed_for_write, FTS5-only with a warning on failure: remember, contradiction.

Retry (3 attempts, 200/400/800 ms) is used by writes only, not by query, document or room embedding. The same cause (embedder unavailable) fails a write as an error when initialisation fails and as a warning when generation fails. There is no embed_batch anywhere.

Direction

One module owns lazy initialisation, the lock, the retry and a declared failure policy (error, or FTS5-only), and the ten call sites ask it. Construction itself stays with the construction issue.

Behaviour impact

Query, document and room embedding gain the retry that writes already have; no panic path remains. Failure messages stay as they are.

Acceptance

• No expect on the embedder remains; no call site locks the embedder itself.
• Retry applies to every embedding call, with the policy tested through a fake that fails N times (the fake from the test-seam issue).
• The failure policy of each call site is explicit in one place and tested (error vs FTS5-only).
• maintenance reembed no longer holds the lock across its loop.

Part of the embedding deepening epic. Easier after the test-seam issue.