Fix FTS5 corruption detection: use MATCH query instead of rowid LIMIT 1

[bgriffin83]

Summary

Fixes silent FTS5 corruption where session_search returns zero results even though the messages table is intact.

Root Cause

The FTS5 corruption detection in _ensure_fts_table() used:

cursor.execute(f"SELECT rowid FROM {table_name} LIMIT 1")

SELECT rowid only reads from the FTS5 content table (a regular b-tree), not the inverted-index b-trees. FTS5 corruption from stale WAL after an unclean shutdown lives exclusively in the index b-trees. So the check passed every time even when the index was trashed, and session_search silently returned nothing.

Fix

Changed the verify query to:

cursor.execute(f"SELECT rowid FROM {table_name} WHERE {table_name} MATCH 'the' LIMIT 1")

MATCH 'the' forces SQLite to traverse the FTS5 inverted-index b-tree. A corrupted index throws OperationalError immediately, which triggers the existing drop-recreate-backfill path — auto-healing on next restart.

Additional Improvements

• Refactored the duplicate FTS5 setup code for messages_fts and messages_fts_trigram into a shared _ensure_fts_table() helper
• Added backfill verification after schema init: compares row counts between the FTS table and messages table, and backfills any missing rows — catches partial index rebuilds that the simple existence check misses

Testing

• 228/228 existing state DB tests pass (test_hermes_state.py + test_hermes_state_wal_fallback.py)
• Verified against a corrupted state.db (integrity-check errors on Trees 5 & 20) — the new query correctly detects corruption, drops, recreates, and backfills

[bgriffin83]

My agent became "dumb" wrt memory from yesterday.. turns out some corruption on the sqlite DB was the cause. Not a pro, but hoping this PR will help others

[teknium1]

Thanks for identifying the FTS read-health gap.

Problems

• Current main still uses an existence-only probe in hermes_state.py:1140-1143, while search_messages() converts sqlite3.OperationalError from the FTS query into an empty result at hermes_state.py:5003-5007. The premise therefore remains relevant, but this branch's old _init_schema() hunk no longer matches the current _fts_table_probe() / _ensure_fts_schema() lifecycle at hermes_state.py:1140-1182.
• The diff adds no regression test. Current main already has a realistic corrupted-FTS fixture at tests/test_state_db_malformed_repair.py:266-275; a salvage should prove that the startup read probe detects this class and that indexed search works after repair.

Suggested changes

• Port the health check into the current FTS setup/recovery flow, preserving its base-FTS and optional-trigram handling.
• Add an end-to-end corrupted-index startup/recovery test using the existing fixture.

Automated hermes-sweeper review.