fix(session_search): add session diversity to CJK LIKE fallback

[sujianddd-dev]

What does this PR do?

Short CJK tokens (<3 chars, common in Chinese 2-char words like \u5199\u5165/\u94fe\u8def)
fall to the LIKE path, which orders by timestamp DESC \u2014 pushing all results
into the current/active session and hiding older matching sessions.

This wraps the LIKE query with ROW_NUMBER() OVER (PARTITION BY s.id) to keep
up to 5 messages per session, ensuring results span multiple sessions.

Related issues

• session_search: FTS5 returns empty results for Chinese/CJK queries #11511 \u2014 Original CJK FTS5 issue
• FTS5 unicode61 tokenizer silently drops CJK characters, LIKE fallback only triggers on zero results #14829 \u2014 CJK characters silently dropped
• session_search returns 0 hits for OR-combined ≤2-char CJK queries (trigram picked but can't match) #20494 \u2014 Short CJK OR queries routing bug
• fix(session-search): route short CJK OR queries to LIKE #20499 \u2014 Fix for short CJK OR query routing

[teknium1]

Thanks for identifying a real recall-starvation path. Current main still orders the short-CJK LIKE fallback by newest timestamp before limiting (hermes_state.py:4982-5000), while discovery fetches a bounded 300-row scan and only then skips/deduplicates sessions (tools/session_search_tool.py:513-569). The per-session window cap directly addresses that ordering problem.

Problems

• No regression test covers the reported path. The CJK tests in tests/test_hermes_state.py:1814-2020 validate matching, filters, snippets, and OR routing, but not a high-volume current session exhausting the discovery scan before an older matching session can surface.

Suggested changes

• Add an end-to-end discovery test in tests/tools/test_session_search.py: seed more than _DISCOVER_SCAN_LIMIT newer short-CJK matches in the current session plus an older matching session, then assert discovery with current_session_id returns the older session.

This is an automated hermes-sweeper review.

[teknium1]

Please add a regression test for this cap through session_search discovery: more than the 300-row scan limit of newer short-CJK matches in the current session plus an older matching session should still return the older session after the current lineage is filtered.