#19591: fix(memory): probe FTS5 availability instead of relying on IF NOT EXISTS

## Problem `CREATE VIRTUAL TABLE IF NOT EXISTS ... USING fts5(...)` silently succeeds when the FTS5 table already exists from a prior SQLite build, even when the `fts5` module is **not loaded** in the current runtime. This causes: - `openclaw status` to report `fts ready` (false positive) - Actual FTS5 queries to fail with `no such module: fts5` - Memory sync errors: `[memory] sync failed (watch): Error: no such module: fts5` ### Who is affected? Any OpenClaw user running **Node 22.x**, which ships SQLite compiled without `SQLITE_ENABLE_FTS5`. The issue is masked when: 1. A previous Node version (or SQLite build) created the FTS5 virtual table 2. The user upgrades/downgrades to a Node version without FTS5 support 3. `IF NOT EXISTS` sees the existing table rows and succeeds without loading the module ### Fix Add a lightweight probe query after table creation: ```typescript params.db.prepare(`SELECT count(*) FROM ${params.ftsTable} LIMIT 1`).get(); ``` If the fts5 module isn't loaded, this query throws `no such module: fts5`, and the catch block correctly sets `ftsAvailable = false`. ### Testing - Verified on Node 22.14.0 (SQLite 3.47.2, no FTS5): correctly reports `fts unavailable` - Verified on Node 24.13.1 (SQLite 3.51.2, has FTS5): correctly reports `fts ready` - Full test suite: 840 passed, 1 pre-existing failure (unrelated Slack threading test) <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds a probe query after FTS5 virtual table creation to verify the fts5 module is actually loaded. This fixes a false-positive "fts ready" status that occurred when Node 22.x (which ships SQLite without FTS5 support) encountered pre-existing FTS5 table rows from a previous SQLite build - the `IF NOT EXISTS` clause would silently succeed without actually loading the module, causing subsequent FTS5 queries to fail with `no such module: fts5` errors. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The change is minimal (5 lines), well-documented, targeted at a specific bug, and has been tested across multiple Node versions. The probe query is safe (read-only SELECT with LIMIT 1), uses a constant table name (no SQL injection risk), and the error handling was already in place. - No files require special attention _{Last reviewed commit: d69d75c} <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} <!-- /greptile_comment -->