Implement speedups for transcription.

docs/Decisions.md

@@ -356,3 +356,43 @@ configuration). If a one-word/garbage transcript ever shows up on those, suspect
 their fp16 encoders and extend this decision.
 **Revisit:** if the onnx-community medium conversions are re-exported with
 working fp16 files, or once WebNN/WebGPU runs can be exercised in CI.
+
+## D-023 — Cross-origin isolation (COOP/COEP) so WASM inference is multithreaded
+**Status:** Accepted (2026-07-15)
+Reported symptom: after D-022 moved medium to q4, a 14 s clip transcribed
+correctly in-browser but "took ages" while native whisper needs seconds.
+Cause: without `crossOriginIsolated` there is no SharedArrayBuffer, and
+onnxruntime-web silently runs its (SIMD-threaded build!) WASM backend on
+**one** thread. Measured on the exact browser runtime (ort-web wasm EP,
+medium q4, the 14.4 s en_aiproblem clip): 52.1 s at 1 thread, 15.3 s at 4
+(ort's default cap once isolation exists), 9.5 s at 12 — a 5.5× speedup.
+**Fix:** `src/index.ts` sends `Cross-Origin-Opener-Policy: same-origin` +
+`Cross-Origin-Embedder-Policy: require-corp` on every response in both serve
+modes (`withIsolationHeaders`). Bun cannot attach headers to an HTMLBundle
+route, so in development the shell moved to an internal `/__shell` route and
+`fetch()` re-serves `/` (and SPA fallbacks) with the headers stamped on. The
+inference worker raises `env.backends.onnx.wasm.numThreads` to
+`min(hardwareConcurrency − 1, 12)` when `crossOriginIsolated` is true (ort
+would otherwise cap at 4; without isolation the default is left alone since
+ort clamps to 1 anyway).
+**Consequences:** COEP `require-corp` blocks cross-origin subresources that
+are neither CORS- nor CORP-approved. Everything the app loads today survives:
+Hub model downloads use `fetch()` in CORS mode, all other assets are
+same-origin, and the service worker preserves the headers it cached, so the
+installed/offline app stays isolated too. Any future cross-origin `<img>`,
+font, or iframe must ship CORS/CORP headers or be proxied same-origin.
+**Verified:** headers present on `/`, worker, sw.js, `/ort/*` in both dev and
+production serve modes; dev HMR asset routes unaffected by the `/__shell`
+indirection. Real-browser thread scaling still deserves a spot check (the
+5.5× number is ort-web under Bun, same runtime but not a browser tab).
+**Amendment (2026-07-15, same day):** threads are per-device now. With
+SharedArrayBuffer newly available, onnxruntime-web's *own* default thread
+count becomes ~4 — and the JSEP accelerator EPs (WebGPU, WebNN) are not
+thread-safe: real-browser WebGPU runs failed at OrtRun with "WebGPU
+validation failed. Buffer with '' label is invalid". The worker now sets
+`numThreads` right before each device attempt (`configureWasmThreads`):
+`min(cores − 1, 12)` for the pure `wasm` device, **explicitly 1** for
+`webgpu`/`webnn` (relying on the default is what broke). onnxruntime-web
+fixes its thread pool at first-session init, so the first attempt in a
+worker decides; a wasm fallback after a failed accelerator attempt may run
+single-threaded until the next worker respawn — correct over fast.