Corrupt cache database is reported as "This SQLite build has no FTS5"

What happens

On a corrupt or unreadable cache database, archive search reports:

This SQLite build has no FTS5; archive search is unavailable.

That sends the user to look at their SQLite build, when the actual problem is the cache file.

Why

fts5_available() (claude_code_log/search.py:332) probes by creating a temp virtual table and swallows sqlite3.Error:

def fts5_available(conn: sqlite3.Connection) -> bool:
    """Runtime feature check — FTS5 is standard but not guaranteed."""
    try:
        conn.execute("CREATE VIRTUAL TABLE temp._fts5_probe USING fts5(x, content='')")
        conn.execute("DROP TABLE temp._fts5_probe")
        return True
    except sqlite3.Error:
        ...

A build genuinely lacking FTS5 and a database that cannot be read both raise sqlite3.Error, so both return False and both reach the same message.

Scope

The behaviour is correct — _build_search_index degrades gracefully and serving pages without search beats refusing to start. Only the diagnosis is wrong.

Possible fix

Distinguish the two before reporting: probe FTS5 on a throwaway in-memory connection (which isolates the capability question from the file), or attempt a cheap read of the database first and report unreadability separately.

Surfaced while verifying that a corrupt cache still degrades gracefully.

Start in claude_code_log/search.py at fts5_available() around line 332, then trace how _build_search_index reports its result. Separate the FTS5 capability check from cache database readability so the diagnostic identifies the actual cause, while preserving graceful serving without search for corrupt caches.