fix(studio): the repair runs off the page's own thread, and a stroke is answered twice so the hand is never held

The graph is seconds of solid arithmetic however large the crop is, and it ran
where the pointer lives: the brush lagged behind the hand for exactly as long as
the model took. The runtime's wasm provider now works in a worker of its own, so
the page keeps drawing while the repair is thought through.

The wait itself stays — it is the model's, not the page's — so a preview paints
the blurred fill first and lets the model's version of the same mask replace it.
Filing and export still wait for the model: the faster answer is for the eye
waiting on the brush and for nothing else.

Measured on the same photo and stroke, worst main-thread gap 3703 ms before and
487 ms after; previews land at 1.0 s and 5.3 s, and the model's render is the one
left on the stage.

docker/frontend/src/engine/inpaint.ts

@@ -99,6 +99,13 @@ function load(): Promise<Loaded> {
       ort.env.wasm.numThreads = self.crossOriginIsolated
         ? Math.min(4, navigator.hardwareConcurrency || 1)
         : 1;
+      // ...and the one thread there is runs in a worker of its own rather than
+      // on the page's own. The graph is seconds of solid arithmetic at this size,
+      // and a second of it on the main thread is a second in which the pointer
+      // does not move: the brush lagged behind the hand exactly as long as the
+      // repair took. The worker loads the same file WASM_DIR serves. WebGPU is
+      // off-thread on its own and ignores this.
+      ort.env.wasm.proxy = true;
       ort.env.webgpu.powerPreference = 'high-performance';
       const session = await openSession(ort);
       return { ort, session };