sanitize_fts5_query strips hyphens/dots instead of space-splitting, making kebab-case terms silently unfindable via FTS

[ohdearquant]

Bug

sanitize_fts5_query (crates/khive-db/src/stores/text.rs) removes - and . from queries instead of replacing them with spaces, which makes any hyphenated or dotted term silently unfindable through the FTS leg.

Pass 1 space-replaces ( ) , :; Pass 2 then filters out * " ' + - ^ . ~ ! $. So:

• query khive-pack-memory → sanitized to khivepackmemory
• indexed content still contains the literal khive-pack-memory, whose trigrams include the hyphens (e-p, k-m, ...)
• the sanitized trigrams (epa, ckm, ...) never occur in the indexed text → 0 hits, no error

Verified empirically against 0.3.0 (in-memory runtime, no embedders, so the text leg is the only leg):

query	hits against content LEGACY-FLAT-NOTE
LEGACY	1
LEGACY FLAT NOTE	matches
LEGACY-FLAT	0
LEGACY-FLAT-NOTE (exact content)	0

Why it matters

• Hyphenated identifiers are the common case in this domain: crate names, kebab-case slugs, UUIDs, CLI flags, ISO dates. Searching for exactly the token you stored returns nothing.
• The failure is silent (0 hits, ok: true), unlike the pre-fix(db): sanitize FTS5 $ metachar and fail-open on FTS search errors #389 hard error, so nothing signals that the query was mangled.
• With embedders enabled the vector leg usually masks the loss, so the bug mostly surfaces as unexplained recall-quality degradation rather than a visible failure; in no-embed/degraded mode (the kg search hard-fails on FTS5 metacharacters instead of degrading #388/fix(db): sanitize FTS5 $ metachar and fail-open on FTS search errors #389 fail-open path itself) it is a total miss.

Suggested fix

Move - and . (and plausibly + ~ ^) from the Pass 2 filter set into the Pass 1 space-replacement set, for exactly the reason the existing Pass 1 comment gives for :: tenant:isolation → tenant isolation, not tenantisolation. LEGACY-FLAT-NOTE → LEGACY FLAT NOTE, whose trigrams all occur in the indexed content, restoring the match.

Characters that FTS5 rejects outright regardless of position ($, quotes, *) stay in Pass 2.

Regression test suggestion: index a document containing a kebab-case token and assert the exact hyphenated query returns it through the text-only path.

[ohdearquant]

Operational impact, beyond test ergonomics: this is a live defect for production recall quality, not just a CI quirk. Any memory.recall or search whose query contains hyphenated tokens (crate names, issue slugs, act-as, kebab-case config keys, ISO dates, UUID fragments) silently loses the FTS leg and rides vector-only. Exact-token lookup — IDs, SHAs, crate names — is precisely where the lexical leg carries the result and where the vocabulary is hyphen-heaviest, so hybrid fusion is degraded on the queries that need FTS most, with no error signaling it.

Related: if the recall/search query path is touched for #394 (per-op embedding latency), this sanitizer fix is worth folding into the same pass.