What & why

Upgrades the native layer to the jni Rust crate 0.22.4 (latest), a major API overhaul, in preparation for the 2.1.0 driver release. This is a Rust-side-only change — the Java public API, JNI ABI / native method symbols, JDK 8 minimum, and the structured ServerException hierarchy are all unchanged.

Branched off main; the unrelated surrealdb 3.1.2 bump is intentionally not included (this PR keeps surrealdb at 3.0.5).

Key changes (jni 0.22 is a major overhaul)

• JNIEnv split into EnvUnowned + Env. Native methods now take EnvUnowned and run their body via Env::with_env. A small with_env_body! macro + resolve_outcome helper keep the existing raw jobject/jstring/jlong return types and the SurrealError::exception sink. (EnvOutcome::resolve requires T: Default, which raw pointers are not, so the outcome is resolved via into_outcome().)
• Signatures & strings: method/constructor signatures → jni_sig!; class/method names → jni_str! (or JNIString for dynamic names); deprecated Env::get_string → JString::try_to_string.
• jni-sys 0.4 makes jboolean = bool — JValue::Bool and the jboolean default closures/params were adjusted.
• JObject → JThrowable via Env::cast_local; typed JObjectArray<JString>; array APIs via JObjectArray/JPrimitiveArray.
• Explicit #[no_mangle] export names are kept (not #[jni_mangle]) so the 189 Java_com_surrealdb_* symbols stay byte-identical — zero UnsatisfiedLinkError risk. (Switching to #[jni_mangle] later is mechanical if preferred.)

Verification

• cargo build / cargo clippy / cargo fmt --all --check — clean (0 warnings)
• nm — 189 Java_com_surrealdb_* export symbols, names byte-identical
• Java suite (against surrealdb 3.0.5 + an in-memory/WS server): 288 passed, 0 failed, 2 skipped (OS-specific) — exercises the structured exception hierarchy and live queries over WebSocket through the real JNI boundary.

Note: cross-compilation (cross.yml) is unaffected by design (jni is host-agnostic, no new system libs) but was not exercised locally — worth a CI run.