Browser client: WebGPU backend with a CPU/GPU selector

[wasabipesto-bot]

Runs the browser client on the GPU through WebGPU, with a backend selector on the page, and adds an end-to-end test that exercises the whole browser stack in CI-shaped environments with no GPU hardware.

Stacked on #99 (merged); the core prep landed there, so this PR touches the backend only twice: one visibility change and one module registration.

The kernel

WebGPU has no shader-int64, so every existing kernel is rejected by a browser's wgpu device. common/src/cubecl_web.rs is the detailed algorithm with no u64 anywhere:

• multi-precision values as 16-bit halves in u32 words; the schoolbook accumulator provably fits u32 ((2^16-1)^2 + 2*(2^16-1) < 2^32, pinned by a unit test)
• digit masks as u32 quads instead of u64 pairs
• the split16 chunk scan, which is what the wgpu targets already used

Structure, comments and naming track the native kernel line for line, so the two review side by side. Batches are 4M candidates, each flushed as its own submission — the same watchdog rationale as #99's ffe33a6, and doubly so in a browser tab.

Correctness

Exact CPU parity on lavapipe, which drives the identical naga→WGSL path a browser uses:

base	candidates	limbs / masks
10	1 000 000	1 limb, one mask
40	2 000 000	2 limbs
62	200 000	2 limbs
80	100 000	above 64: two-mask path
97	50 000	4 limbs, four-mask path

Base 97 is the widest supported base and no other device test in the tree exercises it.

The page

The existing page keeps its structure — same histogram, same rate/statistics, same claim→process→submit flow. What is new:

• a Compute Backend dropdown. CPU keeps the worker pool; a GPU entry appears only when a WebGPU adapter initializes, labelled with the adapter's name. Browsers without WebGPU see the CPU option and a one-line explanation.
• the GPU path runs in one dedicated worker — the device supplies the parallelism — slicing each claim ~32 ways so progress ticks and the stop button stay responsive.
• results merge through the same server-format path as the CPU workers, so submission, histogram and stats code is shared.

Also fixes a real pre-existing bug: the CPU worker read chunkResult.distribution_updates, a field FieldResults has not serialized for some time. The checked-in page only worked against a stale pkg/ build; anyone rebuilding it got an empty histogram.

Testing it end to end

wasm-client/e2e/ (or just wasm-e2e) serves web/search, drives the real page in the Playwright container's headless Chromium, runs the offline benchmark on both backends, and asserts their histograms agree exactly:

=== CPU backend ===  Benchmark processing completed!
=== GPU backend ===  Benchmark processing completed!
CPU and GPU histograms agree exactly

The GPU arm is real: Chromium's SwiftShader supplies a software WebGPU adapter, so wasm → wasm-bindgen → CubeCL → WGSL → WebGPU all execute — no GPU, no host browser, nothing but docker. Between this and the lavapipe suite, three independent implementations agree on the same field: native CPU, browser CPU wasm, and browser WebGPU.

Known limitations

• Real-GPU browser throughput is unmeasured. SwiftShader proves correctness, not speed. Worth a manual pass on real hardware before advertising the feature.
• Detailed mode only. Niceonly's host pipeline is a std::thread::scope MSD filter, which is not browser-shaped; the mode selector is unaffected because the browser client only ever claims detailed fields.
• pkg/ remains a build artifact (just wasm-build), unchanged from before.