Native ip / array<ip> fields don't support CIDR or wildcards

Summary

Quickwit's native ip field type stores IPv4/IPv6 efficiently but the query parser rejects:

• CIDR notation: src_ip:10.0.0.0/8 → "failed to parse query"
• Wildcards: src_ip:10.0.* → "wildcard queries not supported on ip fields"
• Substring patterns: src_ip:*.0.1 → same as above

Exact equality and range queries work, but there's no native network-range or partial-IP matching.

Repro

curl -sS "$QW/api/v1/<index>/search?query=source.ip:10.0.0.0/8"
# → 400, "failed to parse query"

curl -sS "$QW/api/v1/<index>/search?query=source.ip:*10.0*"
# → 400, "wildcard queries not supported on ip fields"

Expected behavior

• CIDR (10.0.0.0/8, 2001:db8::/32) translates to the equivalent ip range internally.
• Wildcard / prefix / substring support on ip fields — either native, or via a documented .text / .keyword multi-field convention similar to Elasticsearch's pattern.

Use case

Security event search: "all traffic from corp subnet 10.0.0.0/8" or "all IPs starting with 192.168" are extremely common. Today, the only way to support these is to maintain a parallel text-typed IP field in the ingest pipeline and route substring/CIDR operators to it — roughly doubling the storage cost of the IP column.

Version

Observed on 0.8.x.

Start by reproducing the CIDR and wildcard requests against the search API and tracing how the query parser handles native ip fields. Compare the existing exact and range behavior with the requested CIDR and pattern cases. Done means the chosen native or documented multi-field approach supports the stated searches without breaking existing queries.