fix(integration): stabilise TestParquetFuzz topk/bottomk tie flake (#7544)

TestParquetFuzz only passed WithEnabledFunctions to promqlsmith.New
and not WithEnabledAggrs, so the generator kept emitting topk /
bottomk queries against tie-prone data (e2e.CreateBlock uses
float64(i+j), and inner sub-expressions like ({a} or {b}) % {a}
collapse to constant 0). Cortex's parquet path and standalone
Prometheus pick different tied series, and sampleNumComparer — which
only compares total sample count across all output series — cannot
reconcile the resulting time-window divergence. Empirically this
fires on ~5 of ~245 PR CI runs over the last 18 days, 4 of those 5
on arm64 (full census in #7543).

Pass promqlsmith.WithEnabledAggrs(enabledAggrs) at
integration/parquet_querier_test.go:172-176. enabledAggrs is already
declared at integration/query_fuzz_test.go:44-46 as
{SUM, MIN, MAX, AVG, GROUP, COUNT, QUANTILE}; this matches the
aggregator restriction used by nine sibling fuzz tests in
integration/query_fuzz_test.go (TestNativeHistogramFuzz,
TestVerticalShardingFuzz, TestProtobufCodecFuzz,
TestBackwardCompatibilityQueryFuzz, and others).

Same trade-off already accepted elsewhere: random fuzz coverage of
topk / bottomk / count_values / stddev / stdvar against the parquet
path is dropped. A deterministic dedicated test is the right shape
if that coverage is wanted later — strengthening sampleNumComparer
or injecting epsilons cannot work (modulo always produces ties).

Fixes #7543

Signed-off-by: Sandy Chen <Yuxuan.Chen@morganstanley.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: sandy2008

integration/parquet_querier_test.go

@@ -172,6 +172,7 @@ func TestParquetFuzz(t *testing.T) {
 	opts := []promqlsmith.Option{
 		// @ modifier and offset disabled: known bug in Prometheus (e.g. predict_linear with @/offset can panic).
 		promqlsmith.WithEnabledFunctions(enabledFunctions),
+		promqlsmith.WithEnabledAggrs(enabledAggrs),
 	}
 	ps := promqlsmith.New(rnd, lbls, opts...)