Support Convex as a database backend for *.db.* sync layer

What problem does this solve?

Corsair's database layer currently requires a SQL connection (pg Pool, better-sqlite3, postgres.js, or Kysely). Apps built on Convex a reactive document database with no SQL connection string can't use the .db. entity-sync feature (auto-upserting API/webhook data into corsair_entities and related tables) without running a second, separate database purely for Corsair. This defeats the "one migration, one connection string" pitch for any team whose primary backend is Convex, forcing either a second DB to maintain or dropping down to .api. only and rebuilding the sync layer by hand.

Proposed solution

Add a Convex adapter alongside the existing SQL adapters likely implemented via Convex's mutation/query functions instead of raw SQL, mapping the four core tables (corsair_integrations, corsair_accounts, corsair_entities, corsair_events) to Convex tables with equivalent schema. Webhook and API-call upserts would call Convex mutations instead of SQL upserts; .db. reads would go through Convex queries. Ideally this fits the same createCorsair({ database, ... }) config shape so switching backends doesn't change call sites like tenant.slack.db.messages.list().

Alternative approaches

Running Corsair against a separate Postgres instance while keeping Convex for the rest of the app works, but means maintaining two databases and losing Convex's reactive queries for exactly the data (live integration state) where "always fresh" matters most. Using only .api. and hand-writing Convex mutations to persist Corsair's responses works, but reimplements the sync/webhook-freshness layer Corsair is meant to provide.

Additional details

No response