Agent-memory workloads: asyncio facade, read-your-writes vector test, vector bulk I/O #306

Agent memory is a write-heavy, many-small-collections workload: an agent inserts a few vectors per turn, queries right away, and several agents may share one process. This issue collects what the Python bindings need for that, apart from the engine-side parts (small-graph rebuilds, default recall), which I will take to ArcadeData/arcadedb with measurements.

What exists today: AsyncExecutor (the engine's async API, including transaction) in both packages, and the concurrency page in the docs. There is no asyncio-native API, so an agent loop written with async def has to wrap every call itself.

Proposal, in the order I would do it:

1. An asyncio facade over the existing calls (query, command, a vector search helper) that runs on a bounded thread pool and keeps one transaction per task. No engine change. It needs tests that run concurrent readers and writers on one database from several tasks, and a documented answer for both builds on what releases the GIL.
2. A read-your-writes test for vector indexes: insert a vector, query it in the next call, from the same task and from another task, and assert it is found. This pins the visibility semantics that agent memory depends on, for the JVM and the native package.
3. Vector bulk input and output without per-row Python: pass a 2-D numpy array in, get the search result as arrays out. An earlier study found the engine itself at parity and the cost in Python-side materialization, so I will measure first (ab.py with the noise gate) and only add what the numbers justify.
4. One docs page for agent-memory use: collection size, when the graph index pays off, what to expect right after a write.

I will attach measurements to this issue as the studies finish. Happy to change the order or drop an item if you see it differently.