Investigate why Utf8View performs worse for sort with high cardinality cases and improve it.

### Is your feature request related to a problem or challenge?

This is a follow-up for the comments:
https://github.com/apache/datafusion/pull/15348#issuecomment-2749309575

Original result:

## **High Cardinality Performance**
| Sorting Method | `utf8` Time (ms) | `utf8_view` Time (ms) | `utf8_view` Improvement |
|----------------------|-----------------|------------------|------------------|
| **merge sorted** | **4.6662** | 5.0999 | **-9.3% (slower)** |
| **sort merge** | **4.7102** | 5.7224 | **-21.5% (slower)** |
| **sort** | **7.0020** | 6.3274 | **9.6% faster** |
| **sort partitioned** | **242.99 µs** | 679.86 µs | **-180% (much slower)** |

### **Observations**
- `utf8_view` **performs worse** for high cardinality cases:
- **merge sorted is 9.3% slower**.
- **sort merge is 21.5% slower**.
- **sort partitioned is 180% slower**, a drastic drop.
- However, `utf8_view` **still improves** the `sort` method by **9.6%**, likely due to reduced string operations.

We need to investigate why Utf8View performs worse for high cardinality cases and improve it.

### Describe the solution you'd like

_No response_

### Describe alternatives you've considered

_No response_

### Additional context

_No response_

No source file or test is named. Start by reviewing the linked pull request comment and reproducing the high-cardinality results for merge sorted, sort merge, sort, and sort partitioned with Utf8View and utf8. Done means identifying why Utf8View regresses and improving the affected sorting cases without losing its benefit for sort.

Written by the indexing model from the issue text.