bench: Scale sort benchmarks to 1M rows to exercise merge path

[mbutrovich]

Which issue does this PR close?

• Partially addresses Revisit ExternalSorter sort strategy and sort_in_place_threshold_bytes #21543. Also needed to properly evaluate the ExternalSorter refactor in perf: Coalesce batches before sorting in ExternalSorter to reduce merge fan-in #21629, which improves the merge path.

Rationale for this change

Current sort benchmarks use 100K rows across 8 partitions (~12.5K rows per partition, ~100KB for integers). This falls below the sort_in_place_threshold_bytes (1MB), so the "sort partitioned" benchmarks always take the concat-and-sort-in-place path and never exercise the sort-then-merge path that dominates real workloads.

What changes are included in this PR?

Parameterizes the sort benchmark on input size, running each case at both 100K rows (existing) and 1M rows (new). At 1M rows, each partition holds ~125K rows (~1MB for integers), which exercises the merge path.

• INPUT_SIZE constant replaced with INPUT_SIZES array: [(100_000, "100k"), (1_000_000, "1M")]
• DataGenerator takes input_size as a constructor parameter
• All stream generator functions accept input_size
• Benchmark names include size label (e.g. sort partitioned i64 100k, sort partitioned i64 10M)
• Data distribution and cardinality ratios are preserved across sizes

Are these changes tested?

Benchmark compiles and runs. No functional test changes.

Are there any user-facing changes?

No.

[mbutrovich]

Running locally each 10M iteration takes like 30 seconds. I have to do --sample-size 10 to get it manageable. Not sure if we think that's a problem.

[mbutrovich]

Let me think if 1M would be a more reasonable size up to still hit what we want.

[Dandandan]

Let me think if 1M would be a more reasonable size up to still hit what we want.

Sounds good - let's try that first?