fix: re-embed deletes the vector it just inserted (single-chunk entries vanish from recall)

[mikestanley00]

Summary

For single-chunk entries, re-embedding could delete the entry's vector from Vectorize, leaving the row in D1 but unsearchable. This deletes only genuinely-stale vectors instead.

Root cause

storeEntry keys a single chunk by the entry id:

id: chunks.length === 1 ? id : `${id}-chunk-${i}`

The re-embed paths use "insert new → delete old", deleting the full previous vector_ids set. For a single-chunk entry the new vector reuses the old id, so the cleanup step deletes the vector that was just inserted. The entry then exists in D1 with vector_ids pointing at a vector that's no longer in the index, so recall never returns it — semantic search, and even exact-term queries, miss it.

Affected: POST /update, the MCP update tool, the large-append re-embed, and the smart-merge / replace capture paths.

Fix

Add deleteStaleVectors(old, new) which deletes only ids not reused by the new embedding, and route the four re-embed sites through it. The genuine full-deletes (forget, conflicting-entry removal) are unchanged.

Reproduce (before this PR)

1. Capture a short (single-chunk) memory.
2. Update it (POST /update), or trigger a smart-merge / replace.
3. recall no longer returns it; wrangler vectorize get-vectors <index> --ids <entryId> returns nothing, though D1 still lists it in vector_ids.

Testing

• Updated the four tests that asserted the old full-delete behavior.
• Added a single-chunk id-reuse regression test.
• npm run typecheck clean; npm run test:coverage → 271 tests pass.

[rahilp]

Thanks @mikestanley00 -- great find and perfect fix! Merging this in to the branch now and will be available in main. I'll be cutting a new release later this week and this will be included in that release! Thank you so much!