fix(engine): match_phrase/match_phrase_prefix matched 0 on array fields - #46

… to 0

Root-caused a real OpenSearch Dashboards bug: a "term" or "match_phrase"
filter on a boolean field (e.g. a stock Flights sample-data dashboard
filtering FlightDelay: true) always returned 0 hits, while a `terms`
aggregation on the SAME field correctly bucketed true/false counts. The
asymmetry (aggregation right, filter wrong) pointed at the query/count
path specifically, not the stored data.

Reproduction took most of the effort here: neither a small hand-built
index, an explicit `_flush`/`_forcemerge` after bulk import, nor a
direct `_reindex` copy of the actual broken index's data ever
reproduced it -- all came back correct. The deterministic trigger
turned out to be simpler than any of those: querying a term/match_phrase
on a boolean field WHILE the bulk-imported data is still memtable-
resident (before any explicit flush) -- exactly what every real bulk
import does, OpenSearch Dashboards' own sample-data importer included,
since nothing in normal operation ever calls `_flush` itself. Verified
by bulk-importing OpenSearch Dashboards' own real flights sample
dataset (fetched via `_reindex`/scroll from a real OSD-populated index)
into a fresh index and querying it immediately, with zero manual
flush/merge -- the same shape every real import produces.

Traced via temporary debug instrumentation (added, used to pin the
defect, then removed -- not part of this diff) across four candidate
code paths before finding the actual one: `do_flush_shard`,
`merge_pass_locked`'s `build_doc_value_columns` call, `scored_columnar`'s
per-segment leaf construction, and `try_shortcut_count`. The query
actually goes through `try_shortcut_count` (`scored_fast_ready` was
false because the memtable still held the just-bulk-imported docs --
correct, since they weren't flushed yet), whose Bool handling was
broken in two independent, compounding ways:

1. `memtable.rs`'s `push_field`: `Value::Bool` was stored ONLY in the
   keyword column ("true"/"false" strings), never in the numeric
   column -- unlike `Value::Number`, which (correctly) populates both.
   The on-disk segment builder (`build_doc_value_columns` in index.rs)
   has always encoded booleans as the numeric f64 bit-pattern of
   1.0/0.0, matching `scored_fast_plan`'s `scoring_leaf` (already
   correct). The memtable's own in-memory representation was the only
   place with the inconsistent, keyword-only encoding.

2. `try_shortcut_count`'s Bool handling: `value.as_f64()` and
   `value.as_str()` both return `None` for a JSON boolean, so the
   memtable-side match count was unconditionally 0 regardless of
   actual content, and the segment-side numeric-column fast path never
   engaged either (falling through toward a confidently-wrong FTS
   lookup instead of a safe fallback). Fixed by coercing `Value::Bool`
   to both the 1.0/0.0 numeric form and the "true"/"false" string form
   up front, mirroring the fix already correct in `scoring_leaf` and
   now in `memtable.rs`'s own encoding.

A third, related but independently-reproducible bug surfaced testing
`match_phrase` specifically (the same query shape OpenSearch
Dashboards' filter bar sends for a boolean-field filter, see the
xerj-query parser fix in a separate PR): `doc_matches_query`'s brute-
force `MatchPhrase` matcher only handled `Value::String` field values
-- a boolean or numeric `_source` field value fell to the `_ => None`
catch-all and never matched any document regardless of value. Fixed by
stringifying `Value::Bool`/`Value::Number` field values the same way
`Value::String` already was, before tokenizing for the phrase match.

Verified end-to-end: bulk-imported the real flights sample dataset
(10000 docs, 2511 true) with zero manual flush, immediately queried
`term`, `match_phrase`, and `terms` agg on `FlightDelay` -- all three
now agree (2511 true / 7489 false), where `term`/`match_phrase`
previously returned 0 unconditionally.

Full ES-compat YAML conformance suite: 1360 passed, 0 failed, 3
skipped -- no regressions. `xerj-engine` unit + integration tests: 156
+ 16 passed, 0 failed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016XJaZygeuRfZfUg2B8tPKU