The asynchronous embedding lifecycle needs a rule for completion order as well as content edits. If a note changes twice while two embedding jobs are in flight, the older job may finish last and replace the newer vector even though every job succeeded.

I would attach the note revision to each job and accept its vector only if that revision still matches the current content. A test can deliberately finish the newer job first, then the older one, and assert that search remains tied to the latest revision. That turns stale-vector detection into a property of writes rather than a periodic cleanup hope.