Leading-`-` / bool.must_not matches documents where the field is absent

Summary

Quickwit's leading-- operator (and bool.must_not) matches every document where the inner clause evaluates false, including documents that don't contain the field at all. This differs from both SQL WHERE NOT x = 'foo' (which excludes NULLs) and Elasticsearch must_not (which excludes missing-field docs).

Repro

Index two docs: {"vendor": "aws"} and {} (no vendor field).

curl -sS "$QW/api/v1/<index>/search?query=-vendor:aws"
# → returns BOTH docs.
# Elasticsearch must_not on the same data returns only the {} doc.
# SQL `WHERE vendor <> 'aws'` returns NEITHER (NULLs excluded).

Expected behavior

Either align - / must_not with SQL+ES semantics (field != value AND field exists), or expose a separate operator with that semantic (field:!value, must_not_exists, etc.) and document the distinction.

Why this matters

Every "does not equal" predicate in a user-facing query layer has to be wrapped in an explicit existence guard (field:[* TO *] AND -field:value) to get expected behavior. The existence guard itself is fragile because the right "exists" syntax varies by field type (see related: field:* silently zero when index_field_presence: false).

Version

Observed on 0.8.x.

No implementation files or tests are named. Start by tracing the query parser and evaluator paths for leading - and bool.must_not, then reproduce the two-document case; done means the chosen missing-field semantics are covered by a regression test and documented.