Optimize the multi-threaded implementation of query $query_id using the tracing/profiling data collected with the run tool:

```
${tracing_data}
```
(exec settings: ${exec_settings_str})

Focus on multi-threading specific bottlenecks:
- Load imbalance: threads finishing at different times (idle cores while work remains).
- Synchronization overhead: lock contention, spin-waits, or barriers that serialize execution.
- False sharing: threads writing to adjacent cache lines, causing cache invalidations.
- Memory bandwidth saturation: too many threads contending for the same memory regions.
- Remaining sequential sections that limit parallel speedup (Amdahl's law).

The base implementation should already run through the shared query pool (`get_query_pool()`,
`parallel_for`, `parallel_reduce<T>`) and be correct at both CORE_IDS=1 and multiple threads. Do
not introduce a separate single-threaded/multi-threaded code path. Preserve the same semantics for
every thread count: private per-thread/per-slice state in the hot loop, deterministic merges after
the parallel region, exact integer/fixed-point accumulation for DECIMAL/INT aggregates, no nested
pool calls, and no shared mutable accumulator/map/output vector in the hot loop.

After making changes, validate correctness and confirm performance improved.
Target: reduce runtime further from $current_rt (${exec_settings_str}). Aim for NUM_THREADS x speedup i.e. linear speedup compared to the single-threaded performance (single threaded runtime: $st_rt).

Turn off trace instrumentation in the run-tool for reliable benchmarking. Call run-tool with trace to gather updated statistics for bottleneck identification.
Make sure the performance improved. Otherwise, try again or remove your changes.

${general_pretext}

$constraints
- Call run-tool only after significant edits. Do not call run-tool after every small change. A single call to the run-tool is sufficient to evaluate a change. Calling in trace mode will provide updated tracing/profiling information.
- Read each file at most once per round. Do not re-read files to look up details you already saw.
- Be carefull with changes that affect other queries${bespoke_storage_related}. Avoid regressions on the other queries.
