Malformed JNI arguments panic instead of returning an error #7183

Describe the bug

Several JNI entry points in native/core/src/execution/jni_api.rs convert their arguments with unwrap() / expect(), so a malformed argument panics instead of returning a CometError:

• convert_datatype_arrays (used by columnarToRowInit, writeSortedFileNative and writeSortedPartitionsNative) calls serde::deserialize_data_type(bytes).unwrap().
• writeSortedFileNative reads its file_path and compression_codec strings with JString::try_to_string(env).unwrap(). traceBegin, traceEnd and logMemoryUsage read their name argument the same way.
• get_execution_context, which executePlan and getShufflePartitionOffsets use, calls .expect("Comet execution context shouldn't be null!") on the handle that the JVM passes in.

try_unwrap_or_throw catches the panic and raises a CometNativeException, so the JVM still gets an exception. However, that exception carries only the panic message, such as called Result::unwrap()on anErr value: ..., without saying which argument was bad. The backtrace is written to the executor's stderr.

Steps to reproduce

The JVM side never passes such arguments today, so this cannot be reproduced through Spark. Reaching it requires a direct native call with a malformed argument, for example a byte array that is not a serialized DataType passed to columnarToRowInit, or a null String passed to traceBegin.

Expected behavior

These conversions return a CometError through ? with a message that names the argument. The exception class stays CometNativeException, and the conversion no longer goes through the panic path.

Additional context

Exports that are not guarded at all (getRustThreadId, NativeBase.release, nativeSupportsPythonUdf) are out of scope.

Willingness to contribute

I can contribute a fix for this bug independently