[BugFix] Reject full-column ORDER BY that reorders key columns of a key-derived range-distribution table (backport #76256)

[mergify]

Why I'm doing:

On a cloud-native range-distribution table whose sort key is key-derived (created without an explicit ORDER BY), a full-column ALTER TABLE ... ORDER BY that permutes the key columns takes the schema-reorder path (processReorderColumn). That reorders the schema — and thus the key-derived range sort key — but the plain lake schema-change job copies each shadow tablet's range verbatim instead of re-sampling. After the flip the sort key is the new key order while the stored boundary tuples are still in the old key-column space, so RangeDistributionPruner (FE) and RangeRouter (BE) compare new-order key tuples against old-order boundaries: silent wrong pruning and mis-routed loads, with no error. The subset ORDER BY form is routed to the range-rewrite job and re-samples, so only the full-column form slips through the orderedColumns.size() != baseSchema.size() dispatch. Reported by @banmoy while reviewing #76047.

What I'm doing:

Reject the corrupting case: a full-column ORDER BY that permutes the key columns of a key-derived (getSortKeyIdxes() == null) cloud-native range-distribution table now fails with a clear message directing the user to the subset ORDER BY (<sort-key columns>) form, which re-samples the K-tablet boundaries. Cases that are already safe are unaffected: a full reorder that keeps the key order (reorders only value columns), tables created with an explicit ORDER BY (the sort key is remapped by name through a reorder), and non-range / non-cloud-native tables. Full support (routing the full reorder to a re-sampling rewrite job) is left as a follow-up enhancement.

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
  • This pr needs auto generate documentation
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.1
  • 4.0
  • 3.5

---

This is an automatic backport of pull request #76256 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 10c0fa5 has failed:

On branch mergify/bp/branch-4.1/pr-76256
Your branch is up to date with 'origin/branch-4.1'.

You are currently cherry-picking commit 10c0fa510f.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   fe/fe-core/src/main/java/com/starrocks/alter/SchemaChangeHandler.java

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
	deleted by us:   fe/fe-core/src/test/java/com/starrocks/alter/RangeRewriteRoutingTest.java

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[mergify]

@mergify[bot]: Backport conflict, please reslove the conflict and resubmit the pr