feat(): load abort signal + harden the message layer

[ShaMan123]

Part of a stack of six PRs that replaces #305. The branches live in a fork, so GitHub can't chain them: every PR is based on main, and the diff of each one includes the PRs below it. Each PR names the commits that are its own and links a comparison that shows only those. They are meant to merge in the order below, and PRs 2 to 6 stay drafts until the one before them is in.

The work. All model state, on both threads, is keyed by the consumer's modelId, and a modelId can be reused. Late async work of a model that was disposed or replaced (a worker reply, queued tiles, a material transfer, a progress event, an in-flight dispose) therefore lands on the next model loaded under the same ID. The stack gives each model an internal uid that is never reused and routes everything by it, adds load({ signal }) (#173), and types the messages between the threads, where most of the bugs it fixes were hidden behind any.

The stack, bottom to top, in merge order:

1. refactor(): route model calls through _invoke #325 refactor(): route model calls through _invoke: mechanical groundwork, no behavior change
2. fix(): type calls to a model's worker, rebuild what the worker copies #326 fix(): type calls to a model's worker, rebuild what the worker copies
3. feat(): load abort signal + harden the message layer #327 feat(): load abort signal + harden the message layer
4. fix(): key models by an internal uid, dispose synchronously #328 fix(): key models by an internal uid, dispose synchronously: the core fix
5. fix(edit): key editor state by the model's uid #329 fix(edit): key editor state by the model's uid
6. refactor(): type the requests workers send to the main thread #330 refactor(): type the requests workers send to the main thread

Every commit in the stack type-checks and passes the test suite on its own, and each PR builds. The top of the stack matches #305's branch merged with today's main, apart from one fix that merge needs (see PR 4) and two reworded lines.

---

This PR's own diff: its last 8 commits, shown here on their own. The commits before them belong to the PRs below.

Description

PR 3 of 6. Adds a signal option to load() (#173), makes every way of aborting a load go through one path, and hardens the message layer between the threads so that a request always settles.

Aborting a load

• load({ signal }): aborting the signal rejects load() with a LoadAbortedError and disposes the partial model. A signal that is already aborted rejects without doing any work.
• abort(modelId) stays, fully supported, and does the same as the signal. Each load owns one AbortController that both go through. abort(modelId) only looks up the load running under that ID, so it keeps no bookkeeping of its own, and an abort can't outlive its load or reach a later load of the same ID. For an ID that isn't loading it does nothing. It used to send a request that spawned a worker.
• Disposing a model while it loads aborts its load too. Before, the load carried on and, with autoCoordinate: false, fired onModelLoaded for the dead model.
• The rejection is a LoadAbortedError instance in every case. It was the worker's serialized error string.
• An abort that lands after the worker finished its part is no longer ignored: load() checks again after each step.
• On the worker, a DELETE_MODEL that lands while its model is still being generated aborts the load and waits for it to unwind. It used to dispose the half-built model from under the generate loop.
• dispose() returns the same promise when it is called again, so a load aborted by a dispose waits for that disposal instead of starting a second one.

Loading an ID that is taken

• Loading a modelId that is already loaded or still loading throws. It silently clobbered the first model, and abort(modelId) needs an ID to name at most one load.
• Only live models count. An ID whose model was disposed can be loaded again as on main, including while its worker still deletes it.

Message layer

• Only CREATE_MODEL assigns a worker to a model. Any other request for a model without one rejects with "model … is not loaded". Before, it spawned a worker that was never released.
• A request that can't be routed rejects. It stayed pending forever.
• An answer goes back through the port its request came in on. It was routed by modelId, so to whichever worker held that ID by then.
• A result that postMessage() can't copy, such as one holding a function, is answered with that error. It threw a DataCloneError as an unhandled rejection and the request never settled.
• MessageBase and ThreadHandler type the message envelope, and fetch() keeps its request's type, in place of any.

Also, load()'s raw option is marked @deprecated in its docs, since compression is detected from the buffer. An explicit value still wins.

From the review of #305

• abort(modelId) is kept, and shares the signal's code path.
• load() doesn't throw while a disposed model is still being deleted on its worker. That window behaves here as it does on main: the race in it predates this PR, and PR 4 closes it by keying models by uid.

Additional context

Everything about aborting is in this PR. PR 4 only swaps the key these lines use, from modelId to uid.

Worth a close look:

• The abort wiring in load(): one controller per load, fed by the signal, abort(modelId) and the model's dispose.
• The worker-side delete during a load, in ThreadModelDeleter and ThreadModelCreator.

Tests: 178 pass, 24 of them new. load-abort.test.ts covers the signal, abort(modelId), disposing mid-load and taken IDs. thread-model-deleter.test.ts runs a delete during a load on the real worker controllers over school_arq.frag. connection.test.ts and fragments-connection.test.ts cover the message layer.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following:

• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Follow the Conventional Commits v1.0.0 standard for PR naming (e.g. feat(examples): add hello-world example).
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

🤖 Generated with Claude Code