fix(changes): actionable error when settings exist but *_cloudsync tables are missing

[andinux]

Problem

Querying cloudsync_changes (directly or via cloudsync_payload_blob_checked()) on a database whose cloudsync_table_settings rows survived while every *_cloudsync meta table was lost — e.g. a dump/restore that skipped them — returned SQLITE_NOMEM: the NULL from vtab_build_changes_sql fell through the config-exists guard added in #54. SQLite Cloud reported it on the /check path as 10000 Not enough memory to execute query, pointing operators at memory instead of the real state (observed in production while diagnosing a customer node).

Fix

cloudsync_changesvtab_filter now distinguishes the state: settings rows present but zero %_cloudsync tables in sqlite_master raises

cloudsync settings reference tables whose sync metadata is missing (no *_cloudsync tables found). Re-run SELECT cloudsync_init('<table_name>') for each configured table to rebuild it.

Genuine OOM (at least one meta table exists) still returns SQLITE_NOMEM.

Testing

• New unit test Changes Vtab Missing Meta Tables: init a table, drop its meta table, assert SQLITE_ERROR with the actionable message. Red before the fix, green after.
• Full SQLite suite: 148/148 OK.
• Verified end-to-end via CLI on a repro database: the query now returns the actionable message instead of out of memory (7).

SQLite vtab only — no PostgreSQL changes, extension version stays 1.1. Bumps CLOUDSYNC_VERSION to 1.1.2 with CHANGELOG entry.

🤖 Generated with Claude Code