[BUG] median columns publish a truncating rolling mean, not a median

[amahussein]

Describe the bug

The median column in stage_level_all_metrics.csv and sql_plan_metrics_for_application.csv is a rolling mean recomputed with integer division per task, so it ratchets toward the floor.

AccumInfo.addAccumToTask maintains StatisticsMetrics.med as (med * count + value) / (count + 1) on every task update, and the source already carries a TODO: update nomenclature from med to rolling average. There are two defects: the value is wrong, because integer division is applied once per task rather than once at the end, so the error compounds; and the name is wrong, because the column is published as median but holds a mean. Every accumulable goes through this path, so CPU-only event logs are affected as well as GPU ones.

Steps/Code to reproduce bug

Run the profiling tool on any event log and open stage_level_all_metrics.csv. Compare the median column against total divided by the stage task count for the same accumulator. On a CPU log from the repository test resources, internal.metrics.executorRunTime reports a median of 1 against a total of 707112.

Expected behavior

The column should report the quantity its name claims. Correcting the arithmetic alone yields an accurate mean still published as median, which is arguably worse than a visibly broken number, so this needs a decision rather than a patch. Either rename the column to mean and compute it as total / count, matching what the GPU aggregation columns now do, which is cheap but renames a shipped column; or keep the name and compute a true median, which requires retaining per-task values.

[amahussein]

AppSQLPlanAnalyzer.generateSQLAccums publishes median for sql_plan_metrics_for_application.csv as Math.max(taskInfo.med, driverInfo.med). taskInfo comes from AccumManager.calculateAccStats, so its med is the truncating rolling mean described above. driverInfo comes from StatisticsMetrics.createOptionalFromArr over the driver accumulable values, and createFromArr calls findMedianInPlace, so its med is a genuine median. The published value is the larger of the two, and which one wins depends on the data.

This constrains the fix rather than sitting beside it: renaming the column to mean is not sufficient at SQL level, because the driver side would then publish a real median under the new name.

The same block does min = Math.max(taskInfo.min, driverInfo.min) and total = Math.max(taskInfo.total, driverInfo.total). The Math.max reads as a way to ignore the ZERO_RECORD placeholder when one side is absent, but it leaves min a maximum of two minima and total a maximum of two sums rather than their combination.