[adsharma]

One SQLite WAL commit now maps to one Ladybug transaction: the batch's statements plus its cursor advance commit atomically.

Motivation. SyncEngine::sync ran every statement through the inner context in autocommit, so a tick with N statements was N transactions. A mid-tick failure left committed prefixes behind — observed live: node upserts for a staged batch committed, then the edge batch failed with Binder exception: Cannot find property _sqlite_rowid on a pre-existing rel table, leaving a half-replicated batch (duplicate memory + entity rows after the fallback applier converged it).

Change (sqlite/src/function/sync_engine.cpp):

• New applyBatchTx wrapper: BEGIN … batch statements … cursor upsert … COMMIT, with ROLLBACK (and stats-restore) on any statement failure.
• All four apply sites (bootstrap, WAL-restart reconcile, DDL reconcile, per-commit incremental loop) go through it; the end-of-tick cursor write is removed in favor of the per-batch in-txn advance, so crash recovery resumes from the last committed SQLite commit.
• DDL (CREATE … IF NOT EXISTS, shadow healing) stays outside the transaction: replay-safe by construction.

Validation.

• New consumer-side regression tests (ladybug-memory-rs, sqlite_first): against the pre-fix build the failed tick leaves (mem, ent, men) = (1, 1, 0); with this build it leaves (0, 0, 0), and the nodes-only batch commits cleanly (via=extension, cursor advanced).
• C++ sync_api_test could not be built in this environment (no gtest available to the standalone extension build); the cdc unit tests cover untouched code. Recommend CI run the full extension suite.

Follow-up (not in this PR): edge _sqlite_rowid slot on pre-existing rel tables — tracked separately.