refactor(db): stop blocking the event loop on sync supabase-py calls

[AbstractNucleus]

What: supabase-py is a sync HTTP client but is called directly from async routes (e.g. home page renders, server detail). Every db.* call blocks the event loop.

Why: Under concurrent load this serializes the whole app on Supabase round-trips. healthz.py already routes db.ping through asyncio.to_thread; nothing else does.

Approach: Either consistently wrap db.* in asyncio.to_thread, or replace with an async PostgREST client (postgrest-py async).

[AbstractNucleus]

This was generated by AI during triage.

Routed to ready-for-human — the wrap-with-to_thread vs replace-with-postgrest-py-async decision has different long-term implications:

• Wrapping is low-risk and reversible but pays a thread-pool cost forever.
• Async client is correct shape but adds a new dependency and changes the error-handling surface.

Pick the direction first, then it can become an agent task.

[AbstractNucleus]

Triage note: two paths, materially different scope.

Path A — asyncio.to_thread wrap (mechanical). Mirror what healthz.py already does for db.ping. Walk every db.* call site and wrap. Maybe introduce a thin db_async shim so route code stays clean. Pros: small, low-risk, no new dependency. Cons: still blocks a thread per call (default executor has a thread cap), and the sync supabase-py keeps eating connections under load.

Path B — replace with async postgrest-py. Move the data layer to an async client end-to-end. Pros: properly non-blocking; matches the rest of the stack (FastAPI, aiodocker post-#149). Cons: supabase-py wraps more than postgrest (auth, storage, realtime — though we may not use those yet); we'd need to swap the client surface and re-test every query.

Recommendation: A first if the goal is just to unblock the event loop on the hot paths, B if we want to converge on an end-to-end async stack. They're not mutually exclusive — A is a stepping stone.

Which direction, and is there an urgency that picks one over the other?