Improve search: multi-term AND + relevance ranking (FTS spike)

[rdhyee]

Summary

Closes #84 — FTS spike complete with immediate search improvements and documented future path.

Shipped now (zero new dependencies):

• Multi-term search: "pottery Cyprus" requires BOTH words to match (was OR on the full phrase)
• Wildcard-safe ILIKE: search terms containing %, _, or \ are escaped, so they match literal characters instead of acting as wildcards
• Relevance ranking: results sorted by score when searching — label match = 3pts, place_name = 2pts. (Description is not scored — the column lives in the wide parquet, while the Explorer's search runs against the lite parquet, which has no description.)
• When not searching, results remain random for exploration variety
• Search composes with active facet filters (Material / Sampled Feature / Specimen Type) and the source legend, so results stay inside the user's current narrowing

FTS spike findings:

• Built offline DuckDB FTS index with tools/build_fts_index.py (preserved as a non-production spike artifact, clearly marked in its module docstring)
• Full index (label + description + place_name): 358 MB — too large for auto-download
• Lite index (label + place_name only): 211 MB — still substantial
• BM25 scoring works well (Porter stemming, English stopwords)
• ATTACH over HTTP in DuckDB-WASM is supported but downloading 200–358 MB is impractical

Recommended next steps (not in this PR):

1. Explore pre-tokenized search parquet (inverted index as parquet, much smaller)
2. Consider on-demand FTS loading behind an "Enhanced Search" toggle
3. Evaluate DuckDB text analytics functions (stemming without full index)

Test plan

• Search "pottery" → results ranked by relevance (label matches first)
• Search "pottery Cyprus" → only samples matching BOTH words
• Search "basalt" → geological samples with label matches at top
• Search "100%" or other wildcard chars → matches the literal characters, not all rows
• Clear search → results return to random sampling
• With Material/Source/Specimen filters active → search results stay inside those filters
• tools/build_fts_index.py runs successfully with local parquet (spike artifact, not part of the deploy)

🤖 Generated with Claude Code

[rdhyee]

Reviewed and pushed two small follow-ups (134aca2):

1. ILIKE wildcard escaping. Search input was passed into the ILIKE pattern with only single-quote escaping, so literal % or _ in the query (e.g. 100%, co_op) silently became wildcards. Now escape % _ \ and add ESCAPE '\' in both the whereClause block and the relevance-score expression.

2. FTS spike script header. tools/build_fts_index.py told readers to "upload to data.isamples.org" but per the PR's own findings the 200-358 MB result is too large to ship. Reframed as STATUS: spike artifact — NOT in production pipeline, kept the script for future revisits, dropped the misleading upload instructions.

Smoke test (/tmp/explorer_smoke_test.py against local Quarto render):

Serving docs on :64856
URL: http://127.0.0.1:64856/tutorials/isamples_explorer.html
JS exceptions:    0
Console errors:   0
Failed requests:  0
RESULT: PASS

Exercised: initial load, multi-term search (pottery cyprus), wildcard-char search (100%). Screenshot confirms the new placeholder and that 100% no longer matches everything.

Other notes from review (not blocking):

• Score expression has discrete plateaus (0/1/2/3/5/6 per term); ties break alphabetically on label. Fine for spike — could mention in placeholder docs later.
• description ILIKE over the wide parquet over HTTP range-fetch may add first-search latency; worth a ?perf=1 measurement before declaring search "done", but out of scope here.

LGTM to merge once you've eyeballed the diff.