fix(memory): delete_all() now enumerates the full ID set, not just the first page

[Solaris-star]

Summary

Fixes #6627

Memory.delete_all() and AsyncMemory.delete_all() fetched the IDs to delete via vector_store.list(filters=filters) without passing top_k. Most vector stores default list(top_k) to 100, so delete_all() silently deleted only the first 100 memories for a scope and left the rest behind — while still returning {"message": "Memories deleted successfully!"}.

This is a data-retention / privacy hazard: a GDPR right-to-be-forgotten request can appear to succeed while personal data remains in the store.

Fix

Pass top_k=10000 to vector_store.list(), matching the full-enumeration cap already used for entity_store.list() in five other places in this module:

# sync
memories = self.vector_store.list(filters=filters, top_k=10000)[0]
# async
memories = await asyncio.to_thread(self.vector_store.list, filters=filters, top_k=10000)

Tests

Added sync + async regression tests asserting top_k=10000 is forwarded to the vector store.

$ pytest tests/test_memory.py -k delete_all -q
4 passed   # 2 new + 2 existing, no regression

Verified both new tests fail on the unfixed code and pass with the fix.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[AmirF194]

Docker-verified this against the PR head (07b6f0f) with a fake vector store that mirrors Qdrant's/Chroma's real list(filters, top_k) signature: a single scroll/get call capped at limit=top_k, no offset or cursor.

top_k=10000 raises the threshold but does not close the gap #6627 describes. With 10,005 memories in one scope, delete_all() still leaves 5 behind and still logs success:

before delete_all: 10005 records for alice
after delete_all:  5 records for alice

Since vector_store.list() has no pagination cursor on any backend I checked, a fixed cap reproduces the same silent partial-delete for any scope larger than the cap, just at a higher count, and it is still silent (no error, no partial-completion signal).

A page-and-relist loop closes it for any size, since each round's list() call naturally returns the next slice once the prior page is deleted, no offset needed. #6629 on this repo does exactly that and I verified it leaves 0 of the same 10,005 records behind.

Non-blocking, just flagging that the cap is a mitigation rather than a fix for the class of bug the PR title claims to close.

[Solaris-star]

Closing in favor of #6636, which is the better fix. My approach just bumped top_k to 10000 (still caps out), while #6636 properly paginates until no matching memories remain and preserves the async partial-failure handling. Deferring to that implementation.