Investigate a DevTools-style visual DB inspector (à la Drizzle Studio)

[eumaninho54]

Context

We don't have any way to visually inspect the on-device SQLite database during development. The pain point today is "I don't know what's actually in SQLite / in the sync_queue right now," which currently can only be answered by db.execute(rawSql).

A visual, real-time inspector for the local database (tables + sync state) would be a meaningful DX differentiator, especially given the sync engine writes to SQLite natively in the background without any JS involved — today that's effectively invisible to the developer.

What to investigate

• What's the minimal native bridge needed to expose a live DB snapshot to an external inspector.
• Could this piggyback on existing infra (e.g. sync_queue, _sync_apply_lock) to also show pending/queued operations, not just table contents — that would be a differentiator versus generic SQLite inspectors.
• Rough scope/cost vs. the syncStatus() observability hook (a cheaper, narrower win already being discussed) — which should land first.

Alternative: Salvetron plugin instead of a standalone inspector

Salve Software already owns salvetron, a real-time terminal UI debugger for React Native: an app-side SDK (@salve-software/salvetron-react-native, built with Nitro Modules) streams telemetry over WebSocket to a terminal UI CLI, which currently shows a performance dashboard, JS logs, native logs, and a network inspector.

Instead of building a separate visual DB inspector from scratch, we could add a database panel to Salvetron itself: react-native-salve-db streams table snapshots and sync_queue state (pending count, last sync, last error) over the same WebSocket channel Salvetron already uses, and it shows up as another panel in the existing TUI. This would:

• Reuse Salvetron's existing transport/SDK instead of building a new bridge and a new client app.
• Put DB state next to network/log telemetry the dev is already watching for the same debugging session — a sync failure would show up alongside the failed request and the log line in one place.
• Be a natural fit for the syncStatus() data mentioned above: that hook's output is exactly what a Salvetron panel would render.

Needs scoping on the Salvetron side too (does its plugin/panel model support a third party like us registering a new panel, or would that require changes in salvetron itself).

Non-goal for now

This is a research/scoping issue, not an implementation task. No code should be written against this issue until scope is defined.