[lumina] Resolve search options through one merge

[jackylee-ch]

Purpose

buildSearchOptions and ensureLoaded each inlined the same three-step merge — table options, then index metadata, then per-query options — while mergeOptions, which is that merge, had no production caller. The only test of the precedence rule therefore asserted against a copy of it rather than against the path a search takes.

Both call sites now go through mergeOptions. No behaviour change: all three copies already had the same order.

The order matters because the metadata records what the index was built with, while the table value may have been changed since. A build-time option read from the table would search an index with parameters it was not built for.

Tests

LuminaSearchOptionPrecedenceTest: a stale lumina.encoding.pq.m=0 and an unset dimension on the table cannot reach the searcher, because the metadata's 8 and 256 override them.

paimon-lumina: 43 run, 0 failures, 25 skipped — the native library ships linux/amd64 only.

Written with Claude Code; verification is mine.

[JingsongLi]

Closing after review. The production diff routes two already-identical option merges through the existing helper, so it does not change the options used by an index load or search. The new tests call the helper directly and do not demonstrate a failing user-visible search on the baseline. I cannot establish end-to-end value for this standalone PR. A reproducer that fails through the reader, with a regression test at that boundary, would justify reopening.