Viewer: show real decode progress, and say clearly when a model is too large for the browser #1195

Summary

Two improvements to how the browser viewer opens models: showing real progress, and handling models too large for the browser.

Checklist

• Real progress. While a model decodes, the progress bar stays indeterminate and the loading card shows an "about N s" estimate from the file size, because the viewer cannot get progress from the decoder (viewer/src/main.ts, near DECODE_BYTES_PER_SECOND). Since feat(cli): rvt-gltf --progress, with saved-graphics stages in WalkerControl #1072 the decoder's WalkerControl reports progress stages for rvt-gltf --progress. Done when the wasm binding passes those stages through viewer/src/worker.ts to the page and the bar shows them, with the estimate kept as a fallback and the Playwright suite covering it.
• Models too large for the browser. WebAssembly can address at most 4 GiB, and a model's decode needs about ten times its file size (Core Interior's 32 MiB file peaks at 324 MiB, feat(viewer): draw doors and windows from their saved meshes, with a toggle #1150). A model like the one behind Bug: models with a partition stream over 256 MiB open empty, with no error #1075 (a 1,057 MiB partition) can fail even after "Retry with large-model limits", and the browser reports only RuntimeError: unreachable. Done when the viewer tells the user plainly that the model is too large for the browser and points them to the CLI. The options for opening larger models (wasm64/memory64, streaming partitions, reading fewer streams) are measured and the choice documented.

Where to start

viewer/src/worker.ts, viewer/src/main.ts, rvt-wasm/src/lib.rs, docs/viewer-api.md, and viewer/tests/saved-meshes-measure.spec.ts, which measures wasm memory per model.