Parquet: Fix variant STRING metrics bounds to use UTF-8 byte order

[vishnuprakaz]

Queries on shredded variant string fields can silently miss matching rows.

Metrics bounds for shredded variant strings are merged across row groups with Java's String.compareTo, but Parquet stats and the read-side evaluator order strings by UTF-8 bytes. The two orders disagree for characters outside the basic plane, like emoji: Java sorts them before some regular characters, UTF-8 after. When a shredded string column spans row groups containing both kinds, the merged lower/upper bounds come out inverted and the metrics evaluator can skip files that actually contain matching rows.

The fix switches variant STRING bounds to Comparators.charSequences(), the same comparator the scan path uses. The BINARY branch already used unsignedBytes() and non-variant strings already used charSequences(); variant STRING was the only case falling back to natural ordering. Same class of bug as #16880.

▎ The bug is in 1.10.0 and 1.11.0; backports will follow.

[uros-b]

Nice fix, thank you @vishnuprakaz!

[vishnuprakaz]

@nssalian could you please take a look. it's similar to #16880.

I also checked whether iceberg-go is affected it isn't, since Go's native string comparison is already byte order.

[nssalian]

lgtm.