Allow co-partitioned `Partitioning::Range` inputs for full hash joins

[gene-bordegaray]

Related:

• #22395
• #21992
• #23183
• #23184
• #23266

Is your feature request related to a problem or challenge?

#23184 lets compatible range-partitioned inputs satisfy inner partitioned hash joins without repartitioning. Full partitioned equi joins still use the conservative repartition path even when both inputs are already co-partitioned by the join keys.

Example

HashJoinExec: mode=Partitioned, join_type=Full, on=[(range_key@0, range_key@0)]
  DataSourceExec: output_partitioning=Range([range_key@0 ASC], [(10), (20), (30)], 4)
  DataSourceExec: output_partitioning=Range([range_key@0 ASC], [(10), (20), (30)], 4)

The compatible range inputs are already co-partitioned by partition index. Matched rows, left-only rows, and right-only rows can still be produced partition-locally.

Describe the solution you'd like

Extend InputDistributionRequirements::co_partitioned(...) to Full partitioned equi hash joins where execution remains partition-local.

Acceptance criteria

• Compatible range/range inputs avoid hash repartitioning for Full joins.
• Incompatible split points, partition counts, sort options, or key expressions still trigger repartitioning.
• Tests cover matched rows, left-only unmatched rows, and right-only unmatched rows.
• Partitioned dynamic filters remain unchanged unless separately addressed by Support dynamic filters for range co-partitioned joins #23376.

Additional context