fix(spec): match Java whitespace for CHAR/VARCHAR partition values

[jackylee-ch]

The CHAR/VARCHAR arm of the partition-value computer folds a value to the default partition name when str::trim leaves it empty, but Rust's whitespace set differs from Java's Character.isWhitespace: str::trim strips a non-breaking space (U+00A0) and U+2007 / U+202F, which Java keeps, and keeps U+001C-U+001F, which Java strips.

The partition value is recomputed on both the write and read paths (BinaryRow -> path), so such a value produces a different partition directory in Rust than in Java, and a cross-engine reader misses the data. The Binary arm already handled this correctly via is_java_whitespace_only (added in #958); the string arm was left on str::trim.

The same str::trim fold also appeared in the Format Table partition paths — format_partition_value (the CHAR/VARCHAR directory value) and the name_prefix_pattern pushdown skip — so those diverged the same way. They are fixed too, matching Java InternalRowPartitionComputer (value folding) and PartitionPathUtils.buildPartitionNamePrefixPattern (the pushdown skip).

Reuse is_java_whitespace_only in every arm so the fold matches exactly what Java folds. Tests cover both divergent directions (U+001C folds, U+00A0 does not) for the spec-side computer and the Format Table value.

[JingsongLi]

Requirement fit: SUPPORTED — partition-path interoperability and correct pruning have end-to-end value. Implementation: FINDINGS at 85b3f917.

[P2] Preserve U+180E partitions written by supported modern JVMs (crates/paimon/src/table/format_partition.rs:322; the native string arm at spec/partition_utils.rs:401 has the same new fold). The reused helper includes U+180E based on its existing JDK 8 binary test. On Java 11/17, Character.isWhitespace('\u180E') is false, and Paimon's StringUtils.isNullOrWhitespaceOnly therefore keeps the literal partition value. The newly changed formatter converts it to the default partition name. Equality pruning then selects that default directory and omits the existing literal partition.

I reproduced this with a real Parquet format table and SQL: an unfiltered scan of a dt=<U+180E>/active=true directory sees its row, but WHERE dt = '<U+180E>' returns no rows at this head. The identical probe returns the row with all three PR-modified production files restored to merge-base 6267e9c0. Local Java 11 and 17 probes both return false for U+180E. Please define the JVM compatibility target explicitly, preserve reads of the modern-Java literal layout, and add this SQL regression rather than extending the JDK 8-only classification to every string path.

Verification: 200/200 partition-filtered core tests passed. The existing DataFusion partition-filter integration test passed; the added U+180E regression failed on the PR and both tests passed on the baseline. Diff check and current-main merge-tree are clean; all 14 head CI checks are green. Temporary edits were restored.