Summary

• sanitize holographic fact_store(action="search") FTS5 queries before they reach MATCH
• quote bare hyphenated and dotted tokens so hostnames like pve-01 stop triggering SQLite parse errors
• add regression coverage for both the raw store search path and the higher-level retriever path

Problem

The holographic memory provider passed raw user queries directly into facts_fts MATCH ?.

For hyphenated identifiers such as pve-01, SQLite FTS5 parses the hyphen as query syntax and raises:

OperationalError: no such column: 01

In practice this broke fact retrieval in two ways:

• MemoryStore.search_facts() raised immediately
• FactRetriever.search() swallowed the FTS error and returned an empty result set, making the failure look like a simple miss

Fix

This PR adds a small _sanitize_fts5_query() helper in the holographic store and uses it in both FTS entry points:

• MemoryStore.search_facts()
• FactRetriever._fts_candidates()

The sanitizer mirrors Hermes' existing SessionDB FTS5 handling:

• preserve balanced quoted phrases
• strip malformed FTS5-special characters/operators
• wrap bare dotted/hyphenated tokens in double quotes

That keeps holographic memory search aligned with the project's existing transcript-search behavior while fixing the concrete pve-01 regression from #14024.

Tests

• pytest -o addopts="" tests/plugins/memory/test_holographic_provider.py

Manual verification

store.search_facts("pve-01", category="hardware", limit=10)
retriever.search("pve-01", category="hardware", limit=10)

Both now return the stored PVE-01 ... fact instead of raising / silently returning [].

Closes #14024