Performance, threads and wasm

Do not block the window

Work that can take long (a feature computation, a save, a file load, reading a picture) runs beside the window and is applied when done. Existing examples: crates/ui-egui/src/save_job.rs, crates/ui-egui/src/file_load.rs, and the agent path in docs/control-protocol.md ("Slow commands and the window").
With the preference "Keep the window responsive while agents run commands" (agent_off_thread) on, a design change that takes longer than about 150 ms is evaluated ahead on a copy of the design, then run for real reusing that result. A person's edit made meanwhile goes first; Stop drops the computation and nothing is applied. Keep that contract when you add a long-running command.
file.export and file.save_mesh change nothing in the design: they run on a copy and nothing waits behind them.
Test it: crates/ui-egui/src/apply_off_thread_tests.rs drives a long feature through the harness; never depend on wall-clock timing in a test.

Profile first. Time with solidcraft-cli from main and from your branch, alternating runs, after the load is low. On a shared machine check cut -d' ' -f1 /proc/loadavg and wait while it is over 24; build with nice.
Report medians with the range, the machine, and the cases. The pattern to follow is docs/perf.md: what was slow, why, the result, and proof that nothing changed (same bodies, volumes, areas and triangle counts).
A speed-up never skips work on a mesh's box: decide with the exact bounds (Body::exact_bounds, grown by the record's tolerance as apart in crates/kernel/src/ops.rs does). A mesh is for display, export, previews and mesh bodies.
Do not rewrite kernel code for speed: the kernel is being replaced, and kernel work is paused. Report a slow case with its file under the kernel-perf label (CONTRIBUTING.md, "Where help is wanted most").
Pull requests run only the tests for what they touch; geometry-heavy tests run in the merge queue. Use cargo xtask test with the ci profile locally (skills/solidcraft-tests/SKILL.md).