What problem does this PR solve?

Window execution currently depends on a separate Sort executor. Sort materializes the input before Window buffers it again, creating an unnecessary second materialization for window queries.

Issue link: N/A

What is changed and how it works?

• Changes the shared tuple sorter to sort an existing row buffer in place.
• Lets the Window executor collect, sort, partition, evaluate, and emit rows from the same buffer.
• Stores partition and ordering fields once in WindowOperator, with the partition field count identifying the boundary.
• Reports the ordering produced by Window directly in its physical sort option, so plans no longer contain standalone Sort nodes for window specifications.
• Keeps separate Window operators for different window specifications, with each operator applying its own ordering.

Code changes

• Has Rust code change
• Has CI related scripts change

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

The coverage verifies in-place tuple ordering, Window executor partition and peer evaluation, ranking and aggregate window results, multiple window specifications, and Explain plans without standalone Sort nodes.

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Note for reviewer

Window remains a blocking operator because it must order its input, but it now performs that ordering in its own row buffer instead of materializing rows in both Sort and Window.