tauri-plugin-syncular — a native syncular instance inside the Tauri process

A NATIVE syncular client (the Rust syncular-client core, consumed DIRECTLY — no FFI) runs in the Tauri host process and is exposed to the webview as Tauri commands + events. The JS bridge (@syncular/tauri) implements the same SyncClientLike interface the React package normalizes, so the hooks work unchanged — the fourth host of one interface after direct / worker-leader / follower.

Decided architecture (ROADMAP.md block 1): NOT JS syncular in the webview — webview OPFS is eviction-prone and inconsistent across WKWebView/webkitgtk; the Rust core gives a real file DB and native perf.

The surface (mirrors the FFI / conformance shim)

• syncular_command(command_json) — the WHOLE command surface in one command ({"method","params"}), dispatched through the shared syncular-command router (the plugin is its THIRD consumer, so the surface stays conformance-locked).
• syncular_query(sql, params) — the React live-query fast path (arbitrary read-only SQL); routed through the same query command.
• syncular_query_snapshot(sql, params, coverage) — atomic reactive reads on an independent read-only SQLite connection for file-backed clients.
• syncular://event — exact revisioned change batches plus ephemeral presence; command/realtime sync intents stay inside the event-driven owner loop.

Thread-safety, honestly

[core::SyncularCore] owns a rusqlite connection and is NOT Sync. One owning thread holds the mutable client; every command arrives over a mailbox (mpsc). The background host loop (§8.4 wake-driven syncUntilIdle with deadlines) runs on that thread. File-backed clients add one read owner with an independent read-only SQLite connection for snapshots, so network work cannot block local views while the mutable client remains single-owned.