Update MIRIX backend to use async native approach

[LiaoJianhe]

MIRIX Async-Native Rewrite

1. Why Async-Native

MIRIX is a multi-agent system where every user request fans out into
database queries, Redis lookups, LLM API calls, embedding computations,
and Kafka messages -- all I/O-bound. The previous sync codebase serialized
these operations: each blocked thread sat idle waiting for a network
response, and concurrency was limited to the thread-pool size.

Rewriting the stack to be async-native delivers several concrete benefits:

Higher throughput on the same hardware.
A single event loop multiplexes thousands of in-flight I/O operations
without dedicating a thread to each one. Connection pools (asyncpg, Redis,
httpx) are shared across all coroutines, so the server handles more
concurrent users with fewer file descriptors, less memory, and less
context-switching overhead.

End-to-end consistency with FastAPI / Uvicorn.
FastAPI is async-first. When route handlers are async def and directly
await the server/manager/agent/LLM chain, there is no implicit offload
to a thread-pool executor. This removes an entire class of subtle bugs
(thread-safety of shared state, session leaks across threads) and makes
the call stack easy to reason about.

Natural streaming and SSE.
LLM token streaming and Server-Sent Events map directly to async
generators. No background thread is needed to feed an SSE response; the
generator yields tokens as they arrive from the LLM provider.

In-process background workers.
Queue consumers (memory extraction, cleanup) run as asyncio.Tasks in
the same process. This simplifies deployment (one container, one process)
while keeping workers non-blocking.

Lower tail latency.
asyncio.sleep-based retries and exponential back-off do not occupy a
thread during the wait, freeing the loop to serve other requests.

---

2. High-Level Changes

2.1 External Library Migrations

Layer | Sync (before) | Async (after) -- | -- | -- Database driver | pg8000 / psycopg2-binary | asyncpg (PostgreSQL), aiosqlite (SQLite) SQLAlchemy | create_engine, sessionmaker, Session | create_async_engine, async_sessionmaker, AsyncSession Redis | redis.Redis | redis.asyncio.Redis with hiredis HTTP client | requests | httpx.AsyncClient OpenAI | openai.OpenAI | openai.AsyncOpenAI Anthropic | anthropic.Anthropic | anthropic.AsyncAnthropic Azure OpenAI | AzureOpenAI | AsyncAzureOpenAI Google AI | sync genai calls | async genai + httpx.AsyncClient Kafka | sync kafka-python (if used) | aiokafka (AIOKafkaProducer, AIOKafkaConsumer) Web search | duckduckgo_search | asyncddgs Google APIs | sync google-api-python-client | aiogoogle Test runner | sync pytest | pytest-asyncio (asyncio_mode = "auto")

3.6 Server Class Naming (Resolved)

The class formerly named SyncServer has been renamed to AsyncServer
as part of this change set. All imports, type hints, docstrings, and tests
have been updated. A backward-compatible alias SyncServer = AsyncServer
is retained in mirix/server/server.py.

---

4. Summary

The MIRIX application is async-native from the HTTP boundary through the
server, agents, service managers, ORM, database, Redis, Kafka, and
LLM/embedding clients. The only remaining sync touch-points are:

1. LangFuse -- sync SDK wrapped in asyncio.to_thread; low impact.
2. Gmail OAuth -- blocking by design; wrapped in to_thread; rare.
3. Startup DDL -- one-time run_sync; no runtime impact.
4. Cleanup script -- asyncio.run() in main; separate process.
5. Pure CPU helpers -- no I/O; async def would add overhead, not benefit.
6. Server naming -- SyncServer renamed to AsyncServer; alias kept.

None of these limit MIRIX's ability to scale request throughput or
concurrent users. The critical path is fully async.