field:* returns 0 hits when index built with index_field_presence: false

Summary

A bare field:* is parsed as the field-presence query, which is backed by the field-presence index. When an index has index_field_presence: false in its doc-mapping, every field:* returns 0 hits regardless of whether the column contains data. The failure is silent — no error, no warning — and is a frequent foot-gun for callers who reasonably read field:* as "field exists."

Repro

# doc-mapping.yaml
index_field_presence: false
field_mappings:
  - name: vendor
    type: text
    tokenizer: raw_lowercase

# Index {"vendor": "aws"}, then:
curl -sS "$QW/api/v1/<index>/search?query=vendor:*"
# → hits: 0. The document and the value exist; the field-presence
#   index was never populated.

Expected behavior

At minimum one of:

1. field:* transparently falls back to a column-index scan when index_field_presence: false.
2. Quickwit emits a parse-time warning (or 400) when field:* is used against an index without field-presence enabled.
3. A separate, discoverable query operator with "exists in column" semantics that does not depend on the field-presence index.

The range form field:[* TO *] empirically works as a workaround, but it isn't documented as an existence check and only works on a subset of field types.

Use case

Multi-tenant indexes where some tenants opt out of index_field_presence for write-throughput reasons. Today this means every exists-style query has to special-case the index config.

Version

Observed on 0.8.x.

Start by tracing how the search API parses a bare field:* query and how that path uses the field-presence index when index_field_presence: false. Compare it with the working field:[* TO *] workaround, then establish which existence semantics and failure behavior should be covered by tests.