ES|QL JSON_EXTRACT: Query-time extraction from JSON data (GA)

## Value Proposition

Retrieve specific elements from JSON data stored in string fields or `_source` using standard JSON path notation, directly within ES|QL queries. Analyze deeply nested JSON content at query time without defining mappings for every nested path or building ingest pipelines to flatten data in advance. Combined with unmapped field loading (also GA in 9.5), JSON_EXTRACT completes a full schema-on-read path in ES|QL.

## Expected Outcome

JSON_EXTRACT shipped in Tech Preview in Elasticsearch 9.4, enabling query-time extraction from JSON content stored in string fields or `_source`.

For GA, JSON_EXTRACT becomes production-ready:

- **Stable function signature and behavior:** JSON path notation for extracting strings, numbers, booleans, arrays, and sub-objects from any string field or `_source`
- **Type coercion:** extracted values can be cast to typed fields for filtering, aggregation, and downstream processing
- **Compatibility with schema-on-read:** works alongside unmapped field loading (`SET unmapped_fields = "load"`) so users can access `_source` fields and parse nested JSON in a single query
- **Performance and correctness fixes:** production-grade reliability for use in alerting rules, scheduled reports, and automated detection workflows

## Who is it for?

Developers and analysts working with semi-structured JSON data: application logs, API payloads, webhook events, and any data source where the schema is partially or fully unknown at ingest time.

## Use Cases

- Parsing nested fields from application log payloads without ingest pipeline changes
- Extracting structured data from semi-structured string fields at query time
- Security investigations across varied log formats where field structures differ per source
- Querying webhook or event data without pre-defining mappings for every possible nested path

Start by reviewing the requested GA behavior and its compatibility with schema-on-read and unmapped field loading described in the issue. The payload names no repository files, tests, or implementation entry points, so identify the existing Tech Preview implementation and its production-readiness gaps before defining completion criteria.

Written by the indexing model from the issue text.