[core] Reject map key type changes in schema merging

[LuciferYang]

Purpose

close #10115

SchemaMergingUtils.merge() recursively merged the key type of a MAP column like any other nested type, so with write.merge-schema and type widening enabled a MAP<INT, V> column could evolve into MAP<BIGINT, V>. The read layer cannot cast map keys: SchemaEvolutionUtil.createMapCastExecutor asserts the input and target key types are equal and throws IllegalStateException otherwise, so after such a merge every pre-change file crashed on scan, compaction, or stats read. The explicit ALTER TABLE ... UPDATE COLUMN path already rejects a map key change; only the merge-schema path let it through.

This throws a descriptive UnsupportedOperationException when the base and update map key types differ, mirroring the method's other merge guards, so the schema change fails up front with an actionable reason instead of producing an unreadable table. The comparison ignores nullability, matching merge()'s contract and the read layer: Spark forces map keys to NOT NULL while core and Flink default to a nullable key, so a key that changes only in nullability is a benign no-op and still merges. Map value types keep merging as before.

Tests

SchemaMergingUtilsTest#testMergeMapTypesWithDifferentKeyTypes: merging MAP<INT,V> with MAP<BIGINT,V> throws UnsupportedOperationException naming "different key types", with and without explicit-cast/type-widening. It fails against the pre-fix code, which widened the key to BIGINT.

SchemaMergingUtilsTest#testMergeMapKeyChangeNestedInRowIsRejected: the same rejection fires on the recursive path, for a MAP nested inside a ROW.

SchemaMergingUtilsTest#testMergeMapKeysDifferingOnlyInNullabilityStillMerges: a map key that differs only in nullability (nullable INT vs INT NOT NULL) still merges, the base key's nullability flows to the result, and the value widens. This guards the nullability-ignoring comparison; a plain equals would wrongly reject the common Flink-table-plus-Spark-merge-write case.

API and Format

no

Documentation

no