Fix bucket-merge scheduling and ReadFromCluster filter staleness

[VighneshPath]

Found via profiling ClickHouse against StarRocks on the IcebergBench cross-engine benchmark. Two independent performance fixes, bundled on one branch as separate commits (unrelated subsystems, found in the same investigation):

1. Aggregator::mergeBlocks: two-level aggregation bucket merges were dispatched in ascending bucket-id order. Real bucket-row-count distributions are skewed, so a large bucket landing anywhere in that order left most merge threads idle early while one thread finished it alone — a straggler tail dominating wall time for wide GROUP BY queries. Now dispatches buckets largest-first (longest-processing-time-first scheduling), so the biggest bucket starts while every thread is still free to help, instead of stranding one thread alone with it at the end.

2. ReadFromCluster (backing icebergCluster(), s3Cluster(), and every other IStorageCluster-based cluster table function): its task/file list was built eagerly from the first applyFilters() call and frozen via a one-shot guard. But query plan optimization calls applyFilters() more than once as the plan is refined — a later pass (e.g. aggregation-in-order for a GROUP BY matching the partition/sort key) can insert another FilterStep above the source, making the filter strictly more complete on a later call. The frozen extension silently dropped anything discovered after the first call. Measured live against Iceberg tables: icebergCluster() read 6-13x more rows than the equivalent ice.\ns.table`query for the identicalWHEREclause, specifically on queries whose plan needed an extra optimization pass.ReadFromObjectStorageStep(the non-cluster object storage path) already gets this right — it defers the equivalent step toinitializePipeline(), which only ever runs after every optimization pass has finished. This change makes ReadFromCluster` follow the same shape.

Both come with unit tests (gtest_aggregator_bucket_merge_order.cpp, gtest_read_from_cluster_predicate_pushdown.cpp) that fail against the pre-fix code and pass against the fix.

Changelog category (leave one):

• Performance Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Improved two-level aggregation merge scheduling to avoid thread-idle tails under skewed bucket sizes, and fixed cluster table functions (icebergCluster(), s3Cluster(), etc.) reading significantly more data than necessary when query optimization refines filter conditions across multiple passes (e.g. GROUP BY on a partitioned column).

Documentation entry for user-facing changes

Not applicable — internal implementation fixes, no new settings or syntax; user-visible effect is fewer files/rows read and less merge-phase tail latency.

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Unit tests
• Performance tests
• Aarch64 tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All Regression
• Disable CI Cache

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• CAS (content-addressed storage; Antalya only)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• OAuth (5m)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

[ianton-ru]

Partially crossed with #2249