[michalharakal]

Summary

Second step of the wasm ↔ JVM parity series (first: #1363, which this branch is stacked on — the BF16/FP16 provider binding from there is what exercises the new 16-bit bodies on wasm). All C changes are in the shared skainet-backend-native-cpu/native/src tree, so the JVM FFM, Android JNI and Kotlin/Native packs build from the same files.

• Explicit SIMD128 bodies for every matmul kernel in the sidecar. Q4_K, Q5_K, Q6_K, Q5_0 and Q5_1 join Q8_0 and Q4_0. The K-quant int8 dots use i32x4.dot_i16x8_s over widened lanes (the SIMD128 stand-in for vdotq_s32), the Q6_K unpack is one lane vector per sub-code, the Q5_0/Q5_1 fifth-bit plane is expanded with a byte swizzle and a per-lane bit test. Helpers live in skainet_simd.h next to the NEON ones.
• Dense FP32 GEMM micro-kernel. The SIMD128 body is a 4×8 register-blocked, k-blocked tile (eight accumulators carried in C between k-blocks). Every output still accumulates in ascending p, so the result is bit-identical to the portable body. The portable and NEON bodies are unchanged.
• BF16 / FP16. Eight weights widen per step on SIMD128 (the branch-free binary16 decode on i32x4 lanes, bit-for-bit the scalar sequence) and on NEON (vcvt_f32_f16); the stream (m == 1) and tile (m > 1) paths both use it. These are the first NEON bodies for the two formats on any tier; the macOS arm64 CI leg runs the FFM parity tests against them.
• Threads for the dense kernels. skainet_fp32_matmul splits C over its longer side, the 16-bit kernels over columns, through skainet_row_threads.h like the packed kernels — the mt sidecar's pthreads in a browser, the native pool on the JVM. Workers own disjoint outputs, so no accumulation order changes.
• WasmCpuOps.matmul. A dense 2-D A · B on heap FP32 operands runs the sidecar GEMM. The common [k, n] loop served that shape before the registry, so it was the one dense path that never reached the sidecar (measured at scalar speed in feat(wasm): BF16/FP16 provider kernels, common KernelStrictness, matrix rows, sidecar features, aligned wasm-bench scenarios #1363's bench).
• Sidecar rebuilt (build-wasm.sh, emsdk 4.0.14): 29 KB st / 44 KB mt.

Measurements (wasm-bench, Node, 12-core laptop; engine-* ids as in jvm-cpu-publish)

Scenario	simd128-st before → after	simd128-mt before → after
engine-fp32-gemm (ops layer, 1024³) GFLOPS	0.74 → 13.83	0.74 → 39.14
engine-kernel-matmul GFLOPS	10.76 → 13.99	7.36 → 40.36
engine-bf16-matmul GFLOPS	6.96 → 7.01	4.42 → 11.88
engine-q4-gemm (Q4_K 4096²) Gops	4.42 → 7.62	14.26 → 24.03
engine-q8-matmul Gops	8.39 → 8.18	24.03 → 27.55

JVM Panama on the same machine: fp32 gemm 15.9, kernel 24.5, bf16 1.5, q4_k 19.3.

Verification

• :skainet-backends:skainet-backend-wasm-simd:wasmJsNodeTest — 7 tests: all seven packed formats against the scalar kernels (K-quant int8 paths on the aggregate relative-RMS gate the JVM tests use, the rest at lane-sum tolerance), the ops-layer GEMM over full tiles, row/column remainders and a k past one 256-block, BF16/FP16 contiguous and windowed, strict mode, features.
• :skainet-backends:skainet-backend-native-cpu:jvmTest — FFM parity for the threaded portable bodies (x86 host); NEON bodies via the macOS arm64 CI leg.
• scripts/pr-gate.sh --quick and the full gate.