Describe the bug, including details regarding any error messages, version, and platform.

I found a possible JNI array leak in FromSchemaByteArray() when the serialized schema cannot be parsed.

File: dataset/src/main/cpp/jni_util.cc

Function: FromSchemaByteArray

Relevant code:

jbyte* schemaBytes_data =
    env->GetByteArrayElements(schemaBytes, nullptr);
auto serialized_schema = std::make_shared<arrow::Buffer>(
    reinterpret_cast<uint8_t*>(schemaBytes_data),
    schemaBytes_len);
arrow::io::BufferReader buf_reader(serialized_schema);

ARROW_ASSIGN_OR_RAISE(
    std::shared_ptr<arrow::Schema> schema,
    arrow::ipc::ReadSchema(&buf_reader, &in_memo))

env->ReleaseByteArrayElements(
    schemaBytes, schemaBytes_data, JNI_ABORT);
return schema;

GetByteArrayElements() returns a pointer that must be paired with
ReleaseByteArrayElements().

ARROW_ASSIGN_OR_RAISE returns immediately when ReadSchema() returns an
error. On that path, the release below the macro is skipped, so the acquired
array elements remain unreleased:

GetByteArrayElements succeeds
  -> ReadSchema returns an error
  -> ARROW_ASSIGN_OR_RAISE returns
  -> ReleaseByteArrayElements is skipped

The function is used by the public native createDataset() method:

schema = JniGetOrThrow(
    FromSchemaByteArray(env, schema_bytes));

Malformed, corrupted, or incompatible serialized schema bytes can therefore
reach this path. Repeated failed calls can retain copied array buffers or keep
Java arrays pinned, depending on the JVM implementation.

Suggested fix: release the elements before propagating the parse result, for
example:

auto schema_result =
    arrow::ipc::ReadSchema(&buf_reader, &in_memo);

env->ReleaseByteArrayElements(
    schemaBytes, schemaBytes_data, JNI_ABORT);

return schema_result;

An RAII guard for schemaBytes_data would also ensure release if additional
early returns are introduced later.