fix(es7): the ES 7 client sends a view's per-group calculation in a transform pivot

[fupelaqu]

What

The ES 7 client can send a materialized view's per-group calculation in a transform pivot.

• Core fix(sql): a view's HAVING reads every aggregate it names; GREATEST/LEAST skip NULL; DATEDIFF per group and by unit #409 added BucketScriptTransformAggregation (e.g. SELECT MAX(a) - MIN(b) AS d in a view) to the transform pivot model. The ES 7 REST client's pivot match had no case for it, so on ES 7 every view with a SELECT calculation failed to deploy: "Unsupported aggregation", thrown client-side. ES 7.17 itself accepts the pivot.
• The client now adds it as a bucket_script pipeline aggregation.
• A calculation that would read script parameters is refused with a clear message instead of being sent unbound. Views already refuse calculations that read the clock, so an accepted view has none.
• Parity: every TransformAggregation subtype now has an ES 7 case (Max, Min, Sum, Avg, Count, Cardinality, TopHits, BucketScript).
• ES 8 / ES 9 send the pivot as JSON and were not affected.

Measured

• New unit test RestHighLevelClientTransformPivotSpec: 2/2. Without the fix: 0/2.
• ES 7.17.29, through the core ES 7 client: transforms with max + min + the calculation, and a bucket_selector reading it, deploy and run.
  • d = 9.0 for the fully populated group and −2.0 for the partial one, and is absent when an operand is NULL.
  • The selector keeps exactly those two groups.
  • The calculation derived from SQL behaves the same.
• ES 8.18.3: identical values.
• Suites: sql 1788, core 1148, ES 7 module 19. Lint is clean.

Not run locally, left to CI: ES 6.8 (no views) and ES 9.0 (JSON path).

Why now

It unblocks the extensions follow-up of #409 (views read every aggregate their HAVING names, plus the calculation channel), whose ES 7 leg needs this case. Merge and publish this first.

🤖 Generated with Claude Code