[Lane 3 · js] Precision/Recall/F1 — JS/Wasm target parity check #1232

Sub-issue of #1222 (Precision, Recall and F1Score metrics).

Lane: 3 · Platform verification · JS / Wasm
Skill needed: Kotlin/JS & Kotlin/Wasm (Node.js, a headless browser via Karma) build tooling — running a Kotlin Multiplatform module's tests on this target. No tensor-internals or metrics knowledge required. The code under test is pure commonMain Kotlin over Double counters; this is a smoke check, not new implementation.
Size: xs (~30–60 min)
Blocked by: #1229 (F1Score merged to develop), or check out its branch early.

What to do

1. ./gradlew :skainet-backends:skainet-backend-cpu:jsTest --tests "sk.ainet.exec.metrics.*"
2. ./gradlew :skainet-backends:skainet-backend-cpu:wasmJsTest --tests "sk.ainet.exec.metrics.*"
   (browser via Karma; wasmWasiNodeTest also exists for the WASI target).

Then, in every case:

• Confirm the metric tests (sk.ainet.exec.metrics.*) pass and the values match the JVM run
  bit-for-bit — pure Long counting and Double division, so any drift is itself a finding.
• Report on [Feature]: Precision, Recall and F1Score metrics #1222: target, toolchain versions, pass/fail, wall-clock, anything
  target-specific you hit (an expect/actual gap, a disabled test source set, a task
  that doesn't exist).

Acceptance

• Result posted on [Feature]: Precision, Recall and F1Score metrics #1222 with the exact Gradle task(s) run
• If something is wrong, a separate bug issue opened and linked — don't block the
  parent on investigating it here

Notes

JS numbers are IEEE doubles, so Double results must match JVM exactly; Long counters
are emulated on JS — an overflow-free smoke test, but worth confirming a batch of a few
thousand samples still counts correctly.