fix(search): make explore find symbols named in CJK (Chinese/Japanese/Korean)

[yimingll]

Problem

codegraph_explore / codegraph explore returns "No relevant code found" for a query written in a CJK script (Chinese, Japanese, Korean) — even when the symbol is indexed and codegraph query / codegraph node find it with the same string.

Repro on a Chinese-named codebase:

$ codegraph query   "寻路服务"              # ✅ finds class 寻路服务
$ codegraph node    "寻路服务"              # ✅ full source
$ codegraph explore "寻路服务"              # ❌ No relevant code found
$ codegraph explore "NavMeshAgent 寻路服务" # ✅ works — an ASCII token rescues it

Root cause

explore derives its search terms via extractSearchTerms() (src/search/query-utils.ts), whose final tokenization is ASCII-only:

const words = normalised.split(/[^a-zA-Z0-9]+/).filter(Boolean);

For an all-ideographic query every character matches [^a-zA-Z0-9], so the split yields only empty strings and the function returns []. context/index.ts then guards the text search with if (searchTerms.length > 0), so nothing is searched. query / node are unaffected because they pass the raw string straight to FTS.

Fix

After the existing ASCII pass (left completely untouched — no change to Latin/accent behaviour), additively recover each ideographic run (\p{Script=Han|Hiragana|Katakana|Hangul}) as its own term. FTS5's default unicode61 tokenizer already stores such a run as a single token (which is exactly why query works), so a whole-run term matches the same way. The floor is 2 chars rather than the ≥3 used to strip short ASCII noise, because an ideographic word is 1–2 characters (寻路 = "pathfinding").

extractSearchTerms("寻路服务")             → ["寻路服务"]              (was [])
extractSearchTerms("寻路服务 自动寻路模块") → ["寻路服务", "自动寻路模块"]
extractSearchTerms("NavMeshAgent类型")      → ["navmeshagent", "类型"]   (Latin part unchanged)

Tests

• New __tests__/extract-search-terms-cjk.test.ts — 7 cases (Han / Kana / Hangul, 2-char words, mixed Latin+Han, plus ASCII-unchanged guards).
• Full npm test is green apart from a few pre-existing, unrelated failures on my Windows box (arkts-resolution, frameworks-integration, mcp-roots, mcp-initialize, plus tinypool "Worker exited unexpectedly"). I verified those fail identically with this change stashed, so they are environmental, not from this PR.

Scope / possible follow-up

This fixes symbol-name / identifier queries (the common case — "find 寻路服务"). A CJK natural-language question has no word spacing, so it still tokenizes as one long run; proper CJK word segmentation would be a separate, larger change.

🤖 Generated with Claude Code