parallelChunks hides a runBlocking(Dispatchers.Default) island inside synchronous kernels

[michalharakal]

Summary

skainet-backend-cpu/src/jvmMain/.../ParallelFor.kt implements parallelChunks as runBlocking(Dispatchers.Default) { coroutineScope { launch { … } } } with a hard-coded availableProcessors() fan-out. Consequences:

1. The calling thread parks for the whole region while all chunks run on Dispatchers.Default — one core idle per matmul.
2. A caller that already runs on Dispatchers.Default (e.g. launch(Dispatchers.Default) { runtime.forward(...) }) parks a pool thread while its own children queue behind it; with cores concurrent forwards the pool deadlocks.
3. Parallelism can neither be switched off nor observed: there is no way to run a kernel single-threaded for a parity check, and no trace of what ran.

Callers: JvmVectorKernels.matmulFloatBlockedMemSeg, JvmQuantizedVectorKernels.matmulQ8_0Vec/matmulQ4_KVec/matmulQ6_KVec, PanamaVectorQ4KMatmulKernel, PanamaVectorQ5_KMatmulKernel.

Fix (in feature/skeep-005-schedules, SKEEP-005)

parallelChunks(outputDim, schedule) delegates to a Schedule carried by the ops (ExecutionContext.schedule). The JVM CoroutineSchedule runs the first chunk on the calling thread, runs nested regions inline (thread-local guard), and offers dedicated(n) with its own pool for callers on Dispatchers.Default. Regions are visible as TraceEvent.ScheduleRegion; Schedule.Sequential makes any kernel single-threaded. Tests: CoroutineScheduleTest (incl. a region started from inside a Default worker).

[michalharakal]

Fixed in #1262 (merged): parallelChunks now delegates to the ops' Schedule instead of hiding its own runBlocking(Dispatchers.Default) island.