Schedule on Android: verify CoroutineSchedule on ART and measure scheduled SDPA on device #1277

Context

0.54.0 introduced Schedule (SKEEP-005): scaledDotProductAttention runs its (batch, head) units on the context's schedule, and the JVM default is CoroutineSchedule.hardware(). The changelog describes the JVM behaviour and the CI deadlock fix (#1262, #1266); nothing states what the Android compilation resolves to.

An encoder-style workload (Whisper: 20 heads × 1500 frames, prefill-shaped, not decode-shaped) is exactly where head-level parallelism pays, and Android big.LITTLE cores make the pool sizing non-obvious (#1196 documented that sleeping pools lose to one pegged big core for sub-millisecond bursts).

Scope

• State and test what DirectCpuExecutionContext() uses as its default Schedule on Android (androidMain actual, or the JVM one via the shared source set?).
• Run the SDPA schedule on a physical arm64 device with prefill shapes ([20, 1500, 64]) and record speedup vs Schedule.Sequential, on big cores only vs all cores.
• Decide whether the JNI row-threading pool (skainet_row_threads, spin-then-park) and CoroutineSchedule should coexist per op or whether one should own the cores on Android; document the choice.
• TraceEvent.ScheduleDowngraded visible on Android when a requested schedule is not honoured.
• An androidTest in skainet-backend-jni-cpu (or skainet-backend-cpu) that exercises a scheduled SDPA on device and asserts bit-identity with sequential.

Acceptance

• The docs' "Schedule getting started" page has an Android paragraph with measured numbers.
• No deadlock or oversubscription when a scheduled op runs inside a JNI-threaded matmul region and vice versa.

Related

• KernelDispatch / KernelRegistry are not safe for concurrent reads #1259, SKEEP-005: schedules — structured concurrency for compute, parallel SDPA, compile-lane metadata #1262, fix(backend-cpu): CoroutineSchedule deadlock that hangs the jvm CI leg #1266 — Schedule introduction and the CI deadlock
• feat(#1195): spin-then-park thread pool for the packed matmul kernels — 153 → 61 ms/step #1196 — threaded packed matmuls and the pool design notes