PR Summary

Medium Risk
Changes the safe-reindex path to stream SQLite embedding-cache rows and introduces async yielding/transaction gating, which could affect reindex correctness/performance if mishandled. Scoped to memory indexing, but touches core sync/reindex logic.

Overview
Memory safe reindex now seeds the embedding cache via streaming iteration instead of materializing all rows up front, and only starts/commits a transaction if at least one row is copied.

The cache-seed loop periodically yields (setImmediate) during large copies, and a new regression test asserts .iterate() is used (and .all() is not) when copying from the original DB into the temp DB used for atomic reindex.

^{Reviewed by Cursor Bugbot for commit 748f3d9. Bugbot is set up for automated code reviews on this repo. Configure here.}

Greptile Summary

This PR replaces .all() with .iterate() in seedEmbeddingCache to avoid materialising every row of the embedding cache into the V8 heap during a safe reindex, and defers opening the SQLite transaction until the first row arrives so empty caches skip the no-op BEGIN/COMMIT. A setImmediate yield every 1 000 rows keeps the event loop available to health probes. The new test explicitly guards that the streaming path is taken by making the .all() overload throw.

Confidence Score: 5/5

Safe to merge — the logic change is minimal, error handling is correct, and the regression test directly verifies the streaming path.

No P0 or P1 issues found. The lazy transaction initialisation, streaming iteration, yield cadence, and ROLLBACK guard are all handled correctly. The test is well-scoped: it reads cached rows from the source DB before installing the spy, drives a forced reindex, and confirms no extra embedding calls were made.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(memory-core): tighten cache seed str..." | Re-trigger Greptile}