fix: preserve inner list field name, nullability and metadata in array_slice (#24341)

[waterWang]

Which issue does this PR close?

Closes #24341.

What changes are included in this PR?

general_array_slice in extract.rs was rebuilding the output list's inner field from scratch using Field::new_list_field(array.value_type(), true), which always produces Field("item", T, nullable: true). This discards the input field's name, nullability, and metadata, contradicting ArraySlice::return_type which promises arg_types[0].clone().

This fix extracts the field from the input array's data type instead, matching the approach already used in general_list_view_array_slice for ListView arrays.

Are these changes tested?

Yes. Added test_array_slice_preserves_inner_field which verifies that the output list type preserves the input field's name and nullability.

Issue body for reference

Describe the bug

ArraySlice::return_type promises arg_types[0].clone(), i.e. the input list type verbatim — inner field name, nullability and metadata included. But the kernel rebuilds the output's inner field from scratch in general_array_slice (extract.rs:685):

Ok(Arc::new(GenericListArray::<O>::try_new(
    Arc::new(Field::new_list_field(array.value_type(), true)),
    ...

That drops the field name (any name → item), drops inner metadata, and forces nullable: true. Whenever the input list's inner field is anything other than Field("item", T, nullable: true), the returned array disagrees with the promised type. On debug builds this trips the return-type assertion added in #17515; on release builds it silently produces a batch whose field name/nullability disagrees with the schema the planner recorded.

This is the same defect fixed for array_sort in #19

[timsaucer]

Would you mind reviewing #24345 instead? It includes SLT tests, which our project prefers.

[Jefffrey]

looks to be part of AI spam