Qualify scoped Spark Omni text path on native Windows RTX

docs/design/omni_edge_e2e_roadmap.md

@@ -327,6 +327,8 @@ outputs need reference analysis; timing alone cannot identify their cause.
 
 The 2026-09-23 [Spark GGUF Omni follow-up](../../benchmarks/edge_harness/results/e2e_expansion_20260923/evidence/spark_omni_llamacpp/README.md) adds a separate native Windows CPU/Radeon 890M whole-session option. Its pinned 1.7B Q4_K_M artifact passed two named complete text requests and 20 serial inventory requests per device through `StageRuntime`/`StagePool`; public `AsyncOmni` short requests passed on both devices. It verifies CPU or Vulkan1 placement, explicit 4 GiB host reservation, terminal event/acknowledgement and cancellation drain. A [2026-09-24 restart audit](../../benchmarks/edge_harness/results/e2e_expansion_20260924/evidence/spark_omni_windows_restart/README.md) confirmed the server had begun the long request before cancellation on each placement, then a fresh StageRuntime with the same artifact returned Paris under a new worker generation with no stale output or reservation. This does not change the vLLM M0 acceptance or establish M1 mobile generation. Its next gates are incremental output, broader token/quality parity, loading/device-memory peaks, concurrency and sustained power/thermal behavior.
 
+The [native Windows RTX Spark GGUF follow-up](../../benchmarks/edge_harness/results/e2e_expansion_20260924/evidence/spark_omni_windows_rtx/README.md) runs that same 1.7B Q4_K_M artifact through an Omni whole-session stage on RTX Vulkan0, with 29/29 layers offloaded. Two named requests, 20/20 serial inventory requests, a public `AsyncOmni` request, context refusal and fresh-stage restart after confirmed in-flight cancellation passed. Its 0.294/0.302 s complete-request p50/p95 is specific to the 2,463-prompt-token/five-output-token serial workload and cannot be compared directly to the earlier Spark 4B BF16 vLLM CUDA results. Token streaming, broad quality, VRAM/load peaks, concurrency and sustained power remain open; this does not establish mobile M1 support.
+
 The [Qwen3-TTS Omni hybrid follow-up](../../benchmarks/edge_harness/results/e2e_expansion_20260923/evidence/qwen_tts_omni_hybrid/README.md) adds one complete-request stage for the native Windows HX370 CPU+Radeon 890M route. A pinned Q8_0 talker and F16 codec produced two named PCM outputs exactly matching the prior standalone backend; one warmup plus 20 serial requests measured 3.298/3.336 s p50/p95 for 2.56 s of audio. Public `AsyncOmni` audio, cancellation drain and explicit 8 GiB host admission passed. A separate [in-flight cancellation audit](../../benchmarks/edge_harness/results/e2e_expansion_20260924/evidence/qwen_tts_omni_windows_restart/README.md) confirmed that the request reached server prefill before cancellation; a fresh stage with the same artifacts and hybrid placement emitted the identical PCM under a new worker generation, without stale output or a retained reservation. This is progress toward M2 integration, not M2 acceptance: RTF remains above 1, and playable chunk streaming, same-session continuation, loading/iGPU peaks, broader voice quality and 30-minute thermal behavior remain open. No NPU participated.
 
 The [WSL CPU Qwen3-TTS Omni follow-up](../../benchmarks/edge_harness/results/e2e_expansion_20260923/evidence/qwen_tts_omni_wsl_cpu/README.md)