ESQL: Add name IDs to golden tests and fix synthetic names

[GalLalouche]

PR Summary

This PR adds support for two golden tests features in ESQL:

1. Name IDs are no longer removed, but are instead normalized, so golden tests can be used to track name IDs.
2. Fixed a bug in synthetic names not being normalized, which could lead to false positives.

Existing discrepancies

Note: There are discrepancies in some of name IDs (Summary by Cursor). @alex-spies, I believe you encountered this in your fixes to #142489!

What the inconsistency is

• In several SubstituteRoundToGoldenTests local physical plans, the same intermediate aggregate fields appear with different NameIds across an ExchangeExec boundary.
• Typical pattern:
  • ExchangeExec output uses IDs like #2/#3
  • direct child (often EsStatsQueryExec) exposes the same logical fields as #4/#5
• AggregateExec FINAL then follows the ExchangeExec side IDs, so the mismatch looks like an Exchange boundary drift.

Why this happens (production path)

• This is not a golden-print normalization issue; it is produced by plan construction.
• The split-agg path creates intermediate attributes more than once in different planning phases:
  1. Mapper builds split aggregate intermediates and stores them on ExchangeExec output.
  2. During local planning (PlannerUtils.localPlan), fragment replanning (LocalMapper) rebuilds intermediate attrs, allocating fresh NameIds.
• ExchangeExec.replaceChild(...) keeps its existing output list, so parent-side IDs and child-side IDs can diverge.

Why it still exists

• The plan remains executable, so this drift can survive verification and only shows up as consistency noise in golden plan structure.
• There is also an explicit TODO in PushStatsToSource noting recreated attributes can get wrong NameIds, which indicates this class of issue is known in planning code.

Why it is not a trivial fix

• A naive fix (for example, always forcing ExchangeExec output to child output IDs) can break split-aggregation runtime semantics.
• We already saw this kind of direct wiring change cause spec IT failures (including TopIpsGrouping) and assertion failures.
• A safe fix needs careful ID propagation/reconciliation across planner phases (Mapper/local mapper/exchange boundaries), not just a 1-2 line tweak.
• Any robust change likely touches planner identity flow and can cause broad golden churn, so it needs targeted validation.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[alex-spies]

LGTM, thanks Gal!