Embedding model record: remaining ways mixed vectors or a stuck repair go unflagged #857

What happens

#855 records which embedding model filled the memory store, and its repair re-embeds the store when the model changes. The review of that PR ran three cycles and left these cases open. In each one, vectors of another model or build can still end up in the store with no repair issue, or a repair cannot finish:

1. An Ollama fallback whose build is unknown can write into the store. A fallback that was down at startup, or whose /api/show did not name its weights, is kept in the embedding chain. When the circuit breaker switches to it later, it writes its build's vectors, nothing reads its build then, and the record does not note it as a writer. The same holds while a repair runs: the repair uses the primary, but conversations and camera captions still embed through the chain.
2. A batch that can never be embedded blocks the repair. One text the provider always rejects (over its input limit, for example) fails every retry. The run stops at the same place, the issue comes back, and every resume hits the same batch.
3. A record check that fails once loses the history. The check runs in the background at the end of setup. If the database times out, the new model starts writing before the record notes it, and switching back later can clear the issue while those vectors stay.
4. Dropping the vector table can raise a needless repair. After DROP TABLE store_vectors and a reload (the documented way to change the size, Embedding store size mismatch with non-Ollama providers, and a missing store table after setup, fail silently #760), the tool index can write new vectors before the record check runs, which then sees vectors under a record that names the old model.
5. A build pulled while Home Assistant runs is noticed only at the next startup (or at the end of a repair).
6. After a host crash, the repair's database lock stays held until PostgreSQL drops the dead connection (about two hours with default keepalives), and a resume meanwhile says another run is re-embedding.
7. A second entry on the same database and model shows the repair issue while the first entry's run holds the lock.
8. After a full re-embed, the vector search index is about twice its size until PostgreSQL vacuums it, and recall can suffer meanwhile; nothing runs a REINDEX.

Expected

Each case either flags the store (a repair issue, or the writer noted in the record) or lets the repair finish.

Notes

• Found in the gstack review of the Memory store: nothing records which embedding model filled it, so a model change silently mixes vectors #855 fix (three cycles, not converged).
• Related: Memory store: nothing records which embedding model filled it, so a model change silently mixes vectors #855, Embedding fallback to a different model mixes vector spaces in stored memories #751, Embedding store size mismatch with non-Ollama providers, and a missing store table after setup, fail silently #760.