Related to #2723

Why

AutoMQ’s Kafka 3.8 merge conflict resolution in b9bad9d29d changed assertParseStringArrayWithNoSchema from Type.ARRAY to Type.MAP, even though both merge parents used ARRAY. The helper parses [...] lists and casts the value to List, so the MAP assertion is wrong and fails ValuesTest.shouldParseStringListWithMultipleElementTypes on both JDK 17 and JDK 21.

The ~131 metadata/KRaft controller failures from #2723 are out of scope.

What

Restore the one-line expectation in ValuesTest.assertParseStringArrayWithNoSchema to Type.ARRAY. Production Values.parseString is unchanged and already returns ARRAY for mixed-element lists.

This is a partial correction toward #2723, not a full resolution of that issue.

How

Keep the array helper aligned with Kafka’s KAFKA-16289 behavior: mixed element types with no common schema still produce an array with a null element schema. Map helpers stay on Type.MAP.

Reviewer notes

• Single assertion in connect/api/src/test/java/org/apache/kafka/connect/data/ValuesTest.java.
• Values.java is not in this PR.
• AutoMQ CI does not run connect:api:test (metadata:S3UnitTest, core:S3UnitTest, s3stream:test only). Please treat the local runs below as the check for this change.
• Please do not treat this as Fixes #2723.

Test plan

• JDK 21: ./gradlew :connect:api:test --tests org.apache.kafka.connect.data.ValuesTest.shouldParseStringListWithMultipleElementTypes
• JDK 17: same test
• JDK 17: ./gradlew --build-cache rat checkstyleMain checkstyleTest spotlessJavaCheck