Affected: Maven: at.yawk.lz4:lz4-java, Maven: org.lz4:lz4-java

### Summary

Insufficient validation of byte array arguments in JNI-based XXHash implementations in lz4-java 1.11.0 and earlier allows callers to crash the JVM by passing an invalid array reference or invalid range to native XXHash methods.

This affects applications where an attacker can influence the byte array object or the `off` / `len` arguments passed to affected XXHash APIs. It does **not** affect the common case where only the contents of a valid byte array are attacker-controlled.

Java-based XXHash implementations are *not* affected.

### Details

The JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are:

- `XXHashFactory.nativeInstance().hash32().hash(byte[] buf, int off, int len, int seed)` - `XXHashFactory.nativeInstance().hash64().hash(byte[] buf, int off, int len, long seed)` - `XXHashFactory.nativeInstance().newStreamingHash32(seed).update(byte[] bytes, int off, int len)` - `XXHashFactory.nativeInstance().newStreamingHash64(seed).update(byte[] bytes, int off, int len)`

Before the fix, the streaming JNI implementations did not validate `bytes`, `off`, or `len` before calling `XXHashJNI.XXH32_update` / `XXHashJNI.XXH64_update`. The non-streaming JNI implementations called `SafeUtils.checkRange`, but `SafeUtils.checkRange(byte[], int, int)` skipped all array access when `len == 0`, so a null byte array with a zero length could still reach JNI.

As a result:

- `hash(null, 0, 0, seed)` and `update(null…