Fix Unicode case-insensitive search for keyword queries

[sadorlovsky]

Problem

The original implementation used the LIKE operator for case-insensitive search which only supports case-insensitive matching for ASCII characters (A-Z), not Unicode. SQLite's LOWER() function also lacks Unicode support, so it wouldn't solve the problem. This caused searches to be case-sensitive for non-English content.

Example:

• Searching for "анна" would NOT find "Анна"
• Searching for "chloé" would NOT find "CHLOÉ"
• Searching for "έλενα" would NOT find "Έλενα"

Solution

Use custom SQLite function lower_unicode() that uses Go's strings.ToLower() for proper Unicode case folding. All keyword search queries now use this function to ensure truly case-insensitive matching across all character sets.

[WithoutPants]

I think we might want to consider adding/changing name indexes to accommodate this.

[sadorlovsky]

I checked this — there is nothing a name index can accommodate here. Keyword search wraps every term as %term%, and with a leading wildcard SQLite does not use a B-tree index for the lookup. EXPLAIN QUERY PLAN for the performer query is identical before and after this change:

SCAN performers
SEARCH performer_aliases USING COVERING INDEX sqlite_autoindex_performer_aliases_1
(performer_id=?) LEFT-JOIN

The existing name indexes were not used for keyword search in the first place — they only serve uniqueness and exact-name lookups, which this PR does not touch.

I also tested expression indexes on lower_unicode(COALESCE(name,'')). SQLite uses them for equality and prefix queries as a control, but for the actual keyword query (LIKE '%term%') the plan remains a scan and the timings are unchanged. In addition, an index on an application-defined function introduces an operational dependency: connections that open the database without registering that function can fail on writes affecting the indexed table and on maintenance operations such as integrity_check, REINDEX, or VACUUM. I don't think expression indexes are a good fit here.

Benchmarks (SQLite 3.45.1 as bundled by mattn/go-sqlite3 v1.14.22, real performer query shape — LEFT JOIN + name OR alias, warm cache, median of 5 runs):

	100k performers	1M performers
plain LIKE '%term%'	33 ms	0.34 s
lower_unicode() scan	0.36 s	3.6 s
+ matching expression indexes	≈ same, plan unchanged	≈ same, plan unchanged
FTS5 trigram MATCH (name only)	0.5 ms	10 ms

The extra cost comes from evaluating the application-defined lower_unicode() function for every scanned row. The latest revision limits this to the cases where it is actually needed: the predicate is chosen per parsed term — ASCII-only terms keep the existing LIKE path (which already provides case-insensitive matching for ASCII), while terms containing non-ASCII characters go through lower_unicode().

This keeps the common search path at the current performance level while fixing the non-Latin case-insensitive search issue.

If we want keyword search to become indexed in the future, that would require a different search approach rather than changing name indexes. SQLite FTS5 with tokenize='trigram' is one possible direction (similar to PostgreSQL pg_trgm), but it would require separate schema/build work and is orthogonal to this fix.

I also merged the latest changes with develop to resolve the conflict.