perf(renderer): adaptive progressive slice sizing

[rowan-m]

Follow-up to the #92 traces. At z=25.7, frame() ran at a steady 60fps for more than 11s with the GPU mostly idle: the fixed worst-case budget came out as about one row per frame, so the full-res render took roughly screen height ÷ 60 seconds.

Change

• Progressive state is now state.nextRow rather than currentPass/totalPasses.
• Renderer learns per-tier throughput (worst-case ops per ms) from each slice's submit-to-done time and sizes the next slice to about 10ms (TARGET_SLICE_MS).
• Slower measurements apply immediately; faster ones at most double the estimate.
• Slices are capped at 16× the old fixed budget (MAX_SLICE_BUDGETS) to bound a stall if a slice runs into interior. Worst case is roughly 16 old slices' worth of GPU time in one frame.
• The first slice uses the old budget, so behaviour starts where it did.
• Interactive previews are unchanged: one full low-res slice.
• Each full-res render records a fractious:full-res User Timing measure, so traces show the time to the final image directly.

Benchmark: reload the same URL and compare the fractious:full-res measure and the rAF span with the main trace. Also check that dragging during a progressive render still responds straight away, especially over interior-heavy views.

Checks: eslint, clippy, WGSL lint, depcruise, wasm + vitest tests (including new Renderer.test.js) and size budgets pass (main JS 13.55 kB). Not visually verified here: no WebGPU in this environment.

[github-actions]

Visit the preview URL for this PR (updated for commit a1d074a):

https://fractious-deep--pr93-perf-adaptive-progre-cpg6acfd.web.app

_{(expires Fri, 02 Oct 2026 09:17:15 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 348393a9746312ebab7a45ce5eba16e6d119af34}