Reduce 2.2s WASM compilation stall on startup

[ysdede]

Trace: Trace-20260213T014231.json (summary in trace_analysis_summary.json)

Evidence

• wasm compilation spike: 2198.78ms ThreadPool_RunTask (v8.wasm TopTierCompilation) on TID 6656
• additional 334ms and 201ms compilation tasks on other threadpool workers

Impact

• Large startup stall before first inference; likely felt as initial UI freeze or delayed transcription start.

Hypothesis

• WASM modules (TEN-VAD, model runtime, or preprocessor) are compiling on-demand during first use.

Actions

• Pre-warm WASM compilation after user gesture (load screen) using WebAssembly.compileStreaming/instantiateStreaming.
• Defer heavy modules until after UI is responsive; optionally show warmup progress.
• Verify whether parakeet.js or TEN-VAD has a cache warming API; enable if available.

Acceptance

• No single wasm.TopTierCompilation task >500ms on first recording start.
• Time-to-first-transcript improves measurably vs this trace.

[ysdede]

Progress update: PR #191 implements a safe warm-up path for TEN-VAD WASM.

What landed:

• one-shot warm-up after first user gesture,
• idle scheduling (requestIdleCallback fallback),
• defer while recording/model loading,
• cleanup cancellation on unmount.

This is intended to shift compile cost away from first recording interaction. Next step is validating trace metrics against this issue acceptance criteria.

[ysdede]

Warmup/idle initialization code already exists in App.tsx (lines 314-495). The 2.2s stall was from first-use on-demand WASM TopTierCompilation. Current code defers init to idle callback. Needs fresh trace to confirm improvement.