feat(KernelRace): add iOS, platform chips, and fix the broken Wasm build - #32

## iOS support

shared/composeApp gain iosArm64/iosSimulatorArm64 targets, mirroring the
existing per-platform expect/actual pattern:

- LlamaRuntimeBuilder.ios.kt: same shape as the JVM actual, backed by
  PosixPreadRandomAccessSource (skainet-io-core's native64Main) instead
  of a JDK file API.
- IosModelProvider.kt: same cache-or-download shape as DesktopModelProvider,
  but talks to Ktor's Darwin engine directly rather than through
  skainet-data-source's KtorRemoteDataSourceFetcher (that module is
  JVM-only per its own gradle.properties — skainet.targets=jvm — so it
  isn't reachable from iosMain at all).
- Platform.ios.kt: reports the Apple native-cinterop kernel tier;
  supportsKernelRace = false (the two-process split-screen race is an
  Android-only mechanism).
- iosApp/: hand-authored Xcode project shell (SwiftUI entry point
  embedding the KMP framework via embedAndSignAppleFrameworkForXcode).
  Structurally checked (balanced pbxproj, valid plist/JSON) but NOT
  built — this environment has no macOS/Xcode, and Kotlin/Native
  requires a macOS host to compile Apple targets at all. First real
  build happens on a Mac.

Prerequisite (separate repo): SKaiNET-transformers PR #315 fixes
kllama's stale iOS/macOS native-kernel install stubs, which were
no-op'd and silently left packed-quant matmul on the scalar floor on
Apple targets. Until that ships in a release, KernelRace's iOS build
runs correctly but without NEON acceleration — noted in the README.

## Platform-support chips

New SamplePlatform enum + currentSamplePlatform expect/actual
(Platform.kt, alongside the existing kernelTierLabel/supportsKernelRace
pattern) and a PlatformChips composable wired into ChatScreen's
Scaffold — a highlighted chip for whichever of Android/Desktop/Web/iOS
is currently running.

## Wasm build fix

The web build compiles but doesn't actually work once deployed: no
Cross-Origin-Opener-Policy/Cross-Origin-Embedder-Policy handling
anywhere, deployed straight to GitHub Pages (which can't set custom
response headers), and Compose's Wasm/Skiko canvas needs cross-origin
isolation (SharedArrayBuffer) for its multi-threaded renderer.
wasmJsBrowserDevelopmentRun's own dev server sets these headers
automatically, which is why this wasn't caught locally — and
kernelrace-ci.yml only runs a compile check, never an actual browser.

Fix: vendor the well-established coi-serviceworker shim (MIT, gzuidhof/
coi-serviceworker v0.1.7) into composeApp's wasmJs resources, loaded
first in app.html.

Verified: built :composeApp:wasmJsBrowserDistribution and served the
production output with a plain static server (no custom headers,
reproducing GitHub Pages) — confirmed neither header is set natively,
confirming the shim is necessary; couldn't verify the actual
browser-side fix (no browser in this environment).

## Verification

- shared/composeApp compile cleanly on every non-Apple target
  (jvm/android/wasmJs) after each change.
- Full existing CI matrix passes: shared:jvmTest, shared:testDebugUnitTest,
  composeApp:assembleDebug, shared/composeApp:compileKotlinWasmJs — 0
  failures, 0 errors across all suites.
- iOS/macOS targets are unverifiable here (no Mac) — noted explicitly
  rather than claimed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Add a concrete "how cheap adding iOS actually was" bullet — ~200 lines
across 4 files, and the one that matters (LlamaRuntimeBuilder.ios.kt) is
36 lines, nearly a line-for-line copy of the JVM actual, with zero
engine-side changes needed. That's the actual point of this sample: it's
meant to demonstrate how easy it is to build apps with SKaiNET, including
on iOS, not just to exercise the engine's targets.

Also fixed the "three kernel paths" count to four now that iOS's
native-cinterop tier exists alongside Android/Desktop/Wasm.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>