feat(java): opt-in copy of each batch the JNI writer imports (workaround for #46) - #47

## Summary

Fixes #46. Provides a zero-copy alternative to the batch-copy workaround
in #47.

A retained validity bitmap or column slice currently keeps an entire
imported Arrow batch alive through its shared C Data Interface release
callback. The new Java-root write path retains each Java allocation
independently, so the writer releases unrelated columns as soon as it no
longer needs them. Spark uses this path by default.

In the nested-string regression workload (16 batches of 8,192 rows),
memory retained before `finish` dropped from about **65 MiB to 8.1
MiB**, with all allocations released at finish. These are synthetic
results; the production 615-column workload has not been rerun.

## Changes

- Add `VortexWriter.writeBatch(VectorSchemaRoot, BufferAllocator)`. It
checks the batch schema, exports the array, and imports it using the
writer's stored schema, avoiding a schema export for every batch.
- Retain Java Arrow reference managers independently and replace the
Rust buffers' owners without copying their data. The last Rust reference
releases its Java allocation, including from native worker threads.
- Preserve Arrow's existing alignment copies for unaligned input. Track
the original exported addresses so missing Java owners still fail import
rather than silently keeping whole batches alive.
- Switch the Spark V2 writer to the new path. The address-based API
remains compatible and keeps the producer's shared release callback; its
callers must use the Java-root overload to get independent allocation
lifetimes. Dictionary-encoded roots still require the address-based API.
- Serialize both write methods with `finish` to prevent access to a
freed native writer, and release the temporary schema used when creating
a writer.

Buffers sharing one underlying Java allocation still share that
allocation's lifetime.

## Testing

- `IndependentBuffersTest`: memory retained before finish and full
release afterward; partial-import and sink-failure cleanup; empty
batches and string views; unaligned integer buffers; schema mismatch
rejection; concurrent write/finish stress for both APIs (16 iterations
each).
- `JNIWriterTest`: both APIs round-trip strings and nested maps. **18
JNI tests pass; one existing test is disabled.**
- Rust ownership tests: unchanged buffer addresses, independent column
release, sliced validity offsets, and release/global-reference cleanup
from a native thread. **3 pass.**
- Spark 2.13 `VortexDataSourceWriteTest`: **11 pass.**
- `cargo clippy -p vortex-jni --all-targets --all-features -- -D
warnings`, pinned Rust formatting, Java formatting checks, and patch
whitespace checks pass.
- Four independent reviews covered reuse, maintainability, efficiency
and correctness; confirmed findings were fixed and tested.

Known separately: the existing Vortex string-view concatenation path
reads metadata from null slots. The view round-trip fixture initializes
those slots; this PR does not fix that issue.

Checked locally against QC `develop`.

I used AI tools to help write and review this change.

Signed-off-by: Christopher Wirt <[email protected]>