[AURON #2497] Fix SortExec projected schema and sort key mapping

[lyne7-sc]

Which issue does this PR close?

Closes #2497

Rationale for this change

SortExec used the full input schema during projected execution and consumed original sort-key indices against the projected schema. Subset or reordered projections could therefore produce an incorrect schema or incorrectly mapped columns.

What changes are included in this PR?

• Use the projected output schema in both projected execution paths.
• Remap sort-key indices against every matching position in the projection.
• Add regression tests for reordered SortMergeJoin projections and strict single-column SortExec projections.

Are there any user-facing changes?

No API changes. Affected projected sort and sort-merge join plans now return columns with the correct schema

How was this patch tested?

Passed unit tests

Was this patch authored or co-authored using generative AI tooling?

• Yes
• No

If yes, include: Generated-by: gpt5

ASF guidance: https://www.apache.org/legal/generative-tooling.html

[slfan1989]

Thanks for fixing the projected SortExec schema and sort-key mapping.

Using the projected schema for both execution paths and remapping the original sort-key indices to their projected positions correctly handles subset and reordered projections.

The new direct SortExec and SortMergeJoinExec regression tests cover the affected paths well.

LGTM.