docs: empty-text search as the listing/count primitive; relevance cutoff makes semantic search non-enumerating

Summary

Two adjacent behaviors of search_long_term_memory that we live-verified on 0.14.0 and found undocumented:

1. Empty-text search is a reliable listing primitive. search_long_term_memory(text="", namespace={"eq": ns}, limit=N) returns the namespace's records without semantic filtering — the only dependable way we found to enumerate/count a namespace.
2. Semantic (non-empty) search applies a relevance cutoff, so it cannot be used to count or enumerate — records that exist simply don't appear for weak queries. We initially misread this as data loss while diagnosing an eventual-consistency question; an explicit doc note would have prevented that.

Ask

Document both: "to list/count a namespace, use empty text; semantic search is top-k with a relevance floor, not an enumeration." If empty-text-as-listing is unintentional and might change, that's even more important to state — consumers (us included: Smart-AI-Memory/attune-ai#666) now depend on it.

Happy to PR the docs note. Context: AMS backs attune-ai's cross-session memory in production.

Start by locating the documentation for the search_long_term_memory entry point and verify the two behaviors described in the issue. Done means the docs explain empty-text listing/counting and clarify that non-empty semantic search is top-k with a relevance cutoff rather than enumeration.