[common] Fix partition getter indexing in InternalRowPartitionComputer

[LuciferYang]

Purpose

close #9512

InternalRowPartitionComputer's constructor sized partitionFieldGetters and partitionCastExecutors by the number of partition columns, then stored into them at the partition column's position in the full row schema. generatePartValues reads all three of partitionFieldGetters[i], partitionCastExecutors[i] and partitionColumns[i] with one loop variable over the partition columns, so the array bound and the index expression have to agree, and they only agree when the partition columns are a prefix of the row type in row order.

Each getter is now stored at its partition-column position, while the type and the field position it reads still come from the row schema.

Nothing in the constructor's signature requires the partition columns to be a row prefix, but every current caller passes a row type already projected to the partition columns in partitionKeys order (TableSchema.logicalPartitionType(), store().partitionType(), rowType().project(partitionKeys()), TypeUtils.project(rowType, partitionKeys)). indexOf therefore always returns the loop position, old and new code produce identical arrays at every call site, and the bug is latent rather than something a deployment hits today. It fires as soon as a caller hands over the full row type: either ArrayIndexOutOfBoundsException, or, when the row positions happen to be in range, a partition spec in which every column name carries another column's value with no error raised.

Tests

Two cases in InternalRowPartitionComputerTest, one per failure mode.

• testPartitionColumnNotAtRowPrefix: row type id, dt, region, extra with partition columns {region, dt}. region sits at row position 2, out of range for a two-element array. Fails on the old code with ArrayIndexOutOfBoundsException: 2.
• testPartitionColumnsReorderedWithinRowPrefix: row type id INT, dt STRING, region STRING with partition columns {dt, id}. Both row positions are in range, so the old code does not throw; it returns {dt=1, id=20240731} instead of {dt=20240731, id=1}. Mixed types make the crossed values visible rather than symmetric.

Both assert with containsExactly(entry(...), entry(...)), which pins the iteration order of the returned LinkedHashMap as well as the pairing, since partition paths and partition specs consume that order.

Verified red before the change (ArrayIndexOutOfBoundsException: 2 and crossed values respectively), and the pre-existing testPartitionToString stays green.

mvn -pl paimon-common test on JDK 8: 12467 tests, 0 failures, 0 errors. checkstyle, spotless, enforcer and rat run clean.