Address PR 29716 review feedback on onnxruntime-web deprecation docs

- WebGPU coverage table (WebGL doc 4.1): switch from pinned MDN 'full support' versions to qualitative status, note WebGPU has shipped by default in Chrome/Edge since 113, keep Firefox as plain 'partial' (no roadmap claim), and link MDN api.GPU as the live source (per Copilot reviewer).

- Migration guide (JSEP doc 11): add guidance to prefer onnxruntime-web/jspi on JSPI-capable browsers for a smaller WASM and lower per-call overhead, with Asyncify as the universal fallback (per qjia7).

- int64 gap (JSEP doc 6): replace the misleading 'CPU-fallback cost' phrasing with the actual cost (CPU/WASM execution of int64-input ops plus partition-boundary copies; no GPU-to-CPU download of int64 data) (per qjia7).

- Remove the Last updated field from both docs.

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Author: edgchen1

docs/design/onnxruntime_web_jsep_to_webgpu_ep_migration.md

@@ -1,6 +1,5 @@
 # Design: Migrate onnxruntime-web WebGPU/WebNN from JSEP to the native WebGPU EP
 
-**Last updated:** 2026-07-14
 **Scope:** `onnxruntime-web` JavaScript/TypeScript package — WebGPU and WebNN backends
 
 **Related work:** [Remove the WebGL (onnxjs) backend from onnxruntime-web](onnxruntime_web_remove_webgl_backend.md)
@@ -149,14 +148,15 @@ kernel only guards int64 *inputs*), so "int64 off" narrows to int64 *inputs*, no
 **Why it's not a blocker.** int64 in real models carries indices/shapes/axes/token IDs, all `≪ 2³¹` (a tensor
 with `> 2³¹` elements can't fit in a `< 2GB` buffer), so JSEP (GPU-truncated) and native-int64-off (CPU-full)
 produce identical numeric results for realistic models — the difference is **performance only**. `transformers.js`
-already runs the native EP with int64 **off** at scale on int64-heavy token-ID models, confirming the
-CPU-fallback cost is acceptable.
+already runs the native EP with int64 **off** at scale on int64-heavy token-ID models, confirming the overhead of
+running those int64-input ops on CPU/WASM (plus the partition-boundary copies — int64 inputs typically originate on
+CPU, and results are uploaded back to the GPU) is acceptable.
 
 **Decision.** Keep int64 **off by default** everywhere, with a uniform native-EP config across `.` and `/webgpu`.
 Migrating JSEP users (always-truncating) to native-int64-off is a correctness *upgrade*. Follow-ups (not
 blockers): (1) an **optional** typed `enableInt64?: boolean` on `WebGpuExecutionProviderOption` as sugar over the
-`extra` key that already works today; (2) benchmark an int64-heavy graph (tokenizer / LLM decode) to quantify the
-CPU-fallback cost.
+`extra` key that already works today; (2) benchmark an int64-heavy graph (tokenizer / LLM decode) to quantify that
+cost (CPU/WASM execution of the int64-input ops plus the partition-boundary copies).
 
 **Graph-capture interaction (resolved).** Graph capture and int64 are coupled inside the EP
 (`enable_int64_{config.enable_graph_capture || config.enable_int64}` in `webgpu_execution_provider.cc`): capture
@@ -300,6 +300,10 @@ EP), so no consumer on the documented path hits an error. Communicated via relea
 - **Default import (`onnxruntime-web`):** no code change needed. The `webgpu` backend continues to work; the
   implementation swaps to the native EP in Phase 1 (this release).
 - **`onnxruntime-web/all`:** continues to work and converges to the native EP.
+- **Lower-overhead build (`onnxruntime-web/jspi`):** when you can target JSPI-capable browsers, prefer the `./jspi`
+  bundle. It runs the **same native WebGPU EP** but bridges async via **JSPI** instead of Asyncify, giving a
+  smaller WASM binary and lower per-call overhead. The default (Asyncify) build remains the universal fallback for
+  browsers without JSPI.
 - **Need JSEP for one more release:** import `onnxruntime-web/jsep` (temporary, deprecated). Please file an issue
   if the native WebGPU EP does not work for your model so the gap can be fixed before JSEP is deleted.
 - **int64-heavy models needing JSEP-identical GPU behavior:** set

docs/design/onnxruntime_web_remove_webgl_backend.md

@@ -1,6 +1,5 @@
 # Design: Remove the WebGL (onnxjs) backend from onnxruntime-web
 
-**Last updated:** 2026-07-14
 **Scope:** `onnxruntime-web` JavaScript/TypeScript package — WebGL backend
 
 **Related work:**
@@ -70,20 +69,23 @@ nothing.
 ### 4.1 WebGPU browser coverage
 
 The historical reason to keep WebGL was "WebGPU isn't available on Safari / iOS / Firefox." As of 2026 that is
-**less true**, though per MDN's `api.GPU` browser-compat data gaps remain:
+**less true** — WebGPU has shipped enabled-by-default in Chrome/Edge since **113** (2023), in Safari (macOS/iOS),
+and in Chrome for Android; Firefox support is partial. Per MDN's
+[`api.GPU`](https://developer.mozilla.org/docs/Web/API/GPU#browser_compatibility) browser-compat data, gaps
+remain:
 
-| Browser | WebGPU (per MDN BCD) |
+| Browser | WebGPU |
 |---|---|
-| Chrome / Edge (desktop) | Full from 144 (Linux: Intel Gen12+ only) |
-| Chrome Android | Full from 121 |
-| Safari (macOS / iOS) | Full from 26 |
-| Firefox (desktop) | Partial from 141 |
-| Firefox for Android | ❌ |
-
-Safari/iOS and Chrome/Edge desktop are solid, but gaps remain (older versions, Firefox for Android, Firefox
-desktop still partial). Coverage is **broadening but not universal**, so the pool of users for whom WebGL is the
-*only* GPU path is shrinking, not gone. The design does **not** assume universal WebGPU — the actionable fallback
-for uncovered users is the WASM/CPU backend.
+| Chrome / Edge (desktop) | ✅ (default since 113; Linux support landed later) |
+| Chrome (Android) | ✅ |
+| Safari (macOS / iOS) | ✅ |
+| Firefox (desktop) | ⚠️ partial |
+| Firefox (Android) | ❌ |
+
+Chrome/Edge and Safari/iOS are solid, but gaps remain (older versions, Firefox for Android, Firefox desktop still
+partial). Coverage is **broadening but not universal**, so the pool of users for whom WebGL is the *only* GPU path
+is shrinking, not gone. The design does **not** assume universal WebGPU — the actionable fallback for uncovered
+users is the WASM/CPU backend.
 
 ---