feat(backend): skainet-backend-jni-cpu — Android JNI bridge for the NEON kernels (#920)

[michalharakal]

The Android half of #920: ART has no java.lang.foreign, so the priority-100 FFM provider can never run there — Android inference has been sitting on the priority-0 scalar floor (the measured 1 tok/s cliff from the field report). This AAR ships the same C kernel sources (CMake includes them from skainet-backend-native-cpu/native — single source of truth) with thin JNI shims and a priority-100 KernelProvider.

Runtime CPU-feature dispatch — the Android-specific trap

A Play-store .so cannot assume armv8.2: dotprod instructions SIGILL on Cortex-A53-class cores, but leaving dotprod off wastes the vdotq_s32 q4k/q6k paths on modern SoCs. Two libs are built from the same sources, and JniKernels loads exactly one per process after checking /proc/cpuinfo:

lib	-march	verified by disassembly
libskainet_jni.so	armv8-a baseline	38 fmla, 0 udot/sdot — safe on every arm64 core
libskainet_jni_v82.so	armv8.2-a+fp16+dotprod	32 udot/sdot sites

Selection-at-load beats symbol renaming / ifunc for simplicity and auditability; the loaded tier is exposed (JniKernelProvider.activeVariant) so field reports name the actual code path.

Details

• Shims: GetPrimitiveArrayCritical (zero-copy pins on ART), no JNI calls inside the critical window, reverse-order releases, JNI_ABORT for read-only arrays; method names contain no underscores (JNI mangles _ → _1). Q8_0/Q4_0/Q4_K/Q5_K/Q6_K bridged; fp32 GEMM deferred (different ABI shape, not the LLM decode hot path).
• Discovery: ART supports java.util.ServiceLoader — PlatformCpuOpsFactory.android now installs discovered providers exactly like the JVM does, then the scalar floor. consumer-rules.pro keeps the service entry + native method names through R8 full mode (without it, release builds silently fall back to scalar — the worst failure mode).
• 16 KB pages: .sos linked with max-page-size=16384 (Android 15+ requirement); LOAD align 0x4000 verified via llvm-readelf.
• ABIs: arm64-v8a + x86_64 (emulator CI); 32-bit ARM deliberately out of scope.
• KernelSupportMatrixTest tier list gains native-jni (Android, priority 100).

Verified locally

• assembleRelease: AAR contains all four .sos (arm64 pair differs — different codegen; x86_64 pair identical by design, no per-ABI loader special case)
• testDebugUnitTest 4/4 — host graceful-degradation contract (no .so → unavailable, kernels null, nothing throws)
• assembleDebugAndroidTest compiles the on-device parity suite (vs scalar references)
• :skainet-backends:skainet-backend-cpu:compileAndroidMain + KernelSupportMatrixTest green

Not yet done (next steps, flagged honestly)

• Device execution of the parity suite and a tok/s measurement on the SmolLM2 reproducer — we'll run both on the physical bench and report numbers in this PR.
• CI instrumented-test lane (emulator) — follow-up per the Ship the aarch64-verified NEON kernels to mobile: Apple targets + Android JNI for skainet-backend-native-cpu (measured 21 → 1.0 → 0.11 tok/s cliff) #920 plan.

Refs #920