Default highlightable? to false for returnable: false fields

[jwils]

Summary

• highlightable? now returns false for returnable: false fields when no explicit highlightable: is set, providing storage savings by default since non-returnable fields don't need to remain in _source for highlighting
• source_excludes_paths now checks highlightable? when deciding what to exclude from _source, so explicitly highlightable: true fields stay available for search highlight snippets even when returnable: false
• Adds highlightable: true to the test schema's internal_name and internal_details widget fields to demonstrate the explicit opt-in pattern
• Adds acceptance test covering filtering, sorting, grouping, aggregating, and highlighting of hidden (returnable: false, highlightable: true) fields

Why only highlightable?

highlightable? is the only -able? predicate where returnable: false creates a meaningful conflict. The other predicates all operate on indexed data (inverted index / doc values), which is always present regardless of _source settings:

• sortable? — Sorting uses doc values, not _source
• filterable? — Filtering runs against the inverted index
• groupable? — Grouping uses terms aggregations on indexed data
• aggregatable? — Aggregations (min, max, avg, cardinality, etc.) use indexed data
• sub_aggregatable? — Nested sub-aggregations also work on indexed data

Highlighting is unique because the datastore must read the original text from _source to produce contextual snippets (<em>matched text</em>). When returnable: false excludes a field from _source, highlighting becomes impossible — making it the only predicate where returnable: false should influence the default.

Test plan

• All 1627 elasticgraph-schema_definition unit tests pass locally
• All 1336 elasticgraph-graphql unit tests pass locally (1 pre-existing unrelated timezone failure)
• Full CI build passes

🤖 Generated with Claude Code