Give exports their own worker

[kmatzen]

Part of #51 — the head-of-line blocking half. This is not cancellation.

Stacked on #50 (base is worker-bridge-correlation-ids), because it builds directly on the correlation-id map. Same consequence as #59: ci.yml only triggers on PRs targeting main, so this gets no CI until #50 merges and GitHub retargets it. Flagging that up front this time.

The problem

The worker runs each message to completion with no yield point (sdfWorker.ts:165), so with a single worker every viewport evaluation queued behind a 256³ export. useEvaluator fires on any store change, so the viewport froze for the duration of an export and then processed a backlog of superseded evaluations.

#50 fixed the settlement bug — before it, an export displaced by an edit never settled at all. But head-of-line blocking was untouched: the hang became a stall.

The change

Two WorkerChannels, each a worker plus its own ready handshake, from one spawn() helper. Evaluates go to one, both export formats to the other.

The pending map stays shared — correlation ids are globally unique, so routing is unchanged — but each entry records its channel, so onerror rejects only that worker's requests. Previously a worker crash rejected everything outstanding; an eval-worker crash now leaves a running export alone.

What's still open in #51

A superseded evaluate runs to completion rather than being cancelled. evalSeq discards results, never work, so rapid edits during a gizmo drag still burn CPU on evaluations whose results are thrown away. They just no longer wait behind exports. Cooperative cancellation — a cancel set checked inside the subdivide recursion at sdfWorker.ts:93 — is the follow-up if you want it.

Testing limitation

Stating this plainly because the test names oversell it: FakeWorker does not block. It records postMessage calls and replays responses on demand, so the test asserting an evaluate settles while an export is outstanding would also pass against the single-worker bridge. It does not prove the viewport stays responsive.

What the tests do verify:

• Routing — evaluates and exports reach separate worker instances. This is the mechanism.
• Crash isolation — an eval-worker failure no longer rejects a running export. New behaviour.
• Every correlation-id guarantee from Route worker responses by correlation id #50 still holds across the refactor.

That the viewport stays responsive during an export follows from the mechanism given the worker is single-threaded and runs each message to completion. That is a sound argument from the code, but it is an argument, not a test. Confirming it needs an e2e that starts an export and checks the viewport still evaluates.

No meaningful discrimination check. Unlike #56–#59, I cannot show these tests failing on the base for the right reason: beforeEach asserts two workers exist, so on the single-worker base all 9 fail with the same harness assertion (expected length 2 but got 1). That tells you the harness changed, not that behaviour did.

Note on CI

If stacked PRs are going to recur here, the blocker is ci.yml's pull_request: branches: [main] filter. Dropping the filter would run CI on every PR regardless of base. One line, but it is a repo policy change so I have not made it.

🤖 Generated with Claude Code

[kmatzen]

Added an e2e test (a874fe8) that measures the property the unit tests can't.

It starts a real 256³ export, waits for the progress bar to confirm it is genuinely in flight, mutates a parameter, waits for the resulting evaluation to land, then asserts the export progress bar is still visible. That ordering is the point: on a single worker the evaluation cannot arrive until the export finishes and the bar is gone, so this fails against the pre-split bridge.

It compares paramValues rather than glsl as the change signal — parameters compile to u_p[] uniforms, so editing a radius changes the values without changing the GLSL string. Watching glsl would never have fired and the test would have passed for the wrong reason.

Also adds data-testid="export-progress", which the progress bar lacked.

I could not run it locally. Playwright's bundled Chromium download failed repeatedly on my machine (killed mid-download, leaving corrupt bundles), and system Chrome launches but never completes its debugging handshake. So the honest status of this PR is:

claim	evidence
requests route to separate workers	unit tests ✅
a worker crash rejects only its own channel's requests	unit tests ✅
correlation-id guarantees survive the refactor	unit tests ✅
exports no longer block viewport evaluation	e2e test written, not yet executed anywhere

CI will run the e2e suite on this PR once #50 merges and GitHub retargets it to main, which will confirm the passing direction. It will not by itself demonstrate that the test fails on the old design — if you want that, I can push a throwaway branch carrying this test without the worker split and open a draft PR so CI runs it red, then close it. Say the word; I did not want to create a deliberately-failing PR unasked.

[github-actions]

🚀 Preview deployed: https://split-export-worker.sinter.pages.dev

(updates on every push to this PR)