…shard join

When both `query_plan_read_in_order_through_join = 1` and
`query_plan_join_shard_by_pk_ranges = 1` are active, two optimizations interact
incorrectly:

1. `optimizeReadInOrder` runs first and converts the outer `ORDER BY` from
   `FullSortingStep` to `FinishSortingStep`, trusting that the MergeTree read
   will produce data in storage-key order through the join.

2. `optimizeJoinByShards` runs afterward and splits the MergeTree read into
   PK-range layers via `splitIntersectingPartsRangesIntoLayers`. This splitter
   intentionally includes the border granule in both adjacent layers so that
   overlapping values can be merge-resolved within each shard. However, no
   cross-shard merge is performed for the outer `ORDER BY`, so each shard
   emits rows in DESC storage order independently and the outputs are
   concatenated, producing wrong results (e.g. `4,3,2,1,0,9,8,7,6,5`
   instead of `0..9` for a table with `ORDER BY (c0 DESC)`).

The root issue is that `optimizeReadInOrder` cannot know that a later pass
will introduce overlapping shard boundaries that break its ordering assumption.

Fix: in `buildInputOrderInfo`, when the optimization traverses through a JOIN
(`joins_to_keep_in_order` is non-empty) and `query_plan_join_shard_by_pk_ranges`
is also enabled, skip the sort elimination. This preserves the outer `ORDER BY`
as a `FullSortingStep` so the data is correctly sorted after the sharded join.

Adds regression test `04075_shard_join_read_in_order_reverse_key` that pins all
settings required to trigger the bug deterministically, including
`enable_join_runtime_filters = 0` (prevents a runtime filter step from
accidentally blocking `findReadingStep` in `optimizeJoinByShards`) and
`merge_tree_read_split_ranges_into_intersecting_and_non_intersecting_injection_probability = 0`
(disables CI chaos injection that would otherwise randomize range splits).

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…overloads

The previous fix only guarded buildInputOrderInfo(SortingStep &...). The same
read-in-order-through-join traversal is also performed by the AggregatingStep
and DistinctStep overloads, which would make an ordering assumption that
optimizeJoinByShards then invalidates by splitting the MergeTree read into
overlapping PK-range layers via splitIntersectingPartsRangesIntoLayers.

Add the same early-return guard in the ReadFromMergeTree branch of both
overloads. Note that MergingAggregatedStep and the final DistinctStep already
produce correct results even with overlapping shard boundaries (two-phase
execution handles the border granule duplication), so these guards are
defensive: they prevent the optimizer from building a plan on a per-shard
ordering assumption that no longer holds after sharding.

Extend the regression test with queries covering both paths.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>