[tisonkun]

Which issue does this PR close?

No linked issue.

Rationale for this change

AsyncExecutor.createTokioExecutor(0) reaches Tokio's worker-thread assertion and terminates the JVM through the JNI panic handler. A subprocess reproduction on the base revision exits with code 134 instead of throwing a Java exception. The native entry point also receives Java's signed 32-bit int as Rust's pointer-sized usize.

What changes are included in this PR?

• Receive the worker count as JNI jint and reject non-positive values with IllegalArgumentException before converting to usize or constructing the runtime.
• Document the positive worker-count requirement and exception on the Java API.
• Add a subprocess regression test that rejects zero, minus one, and Integer.MIN_VALUE, then creates a valid executor and completes an in-memory write/read in the same JVM.

Validation on macOS ARM64 with JDK 25: the new regression test fails before the fix and passes afterward; ./mvnw verify passes all 26 executed tests, and Spotless, Rust formatting, and Clippy with warnings denied pass. External-service behavior suites were not configured. Other operating systems and JDK versions remain for CI validation.

Are there any user-facing changes?

Zero and negative worker counts now throw IllegalArgumentException from AsyncExecutor.createTokioExecutor.

Breaking changes

AI Usage Statement

• Harness: Codex desktop. Model: GPT-6; the exact variant and reasoning-effort setting were not exposed. Role: source inspection, independent reproduction, implementation, regression testing, and PR drafting under maintainer direction.
• Harness: ASVS scanning tool. Models listed in its metadata: gemma4-26b, qwen3-8b, and qwen3.8-27b; reasoning-effort settings were not supplied. Role: supplied the initial executor-parameter finding; the JVM termination was independently reproduced against the Java binding.