Allow queued earcut work to be discarded when its layer is finalized

[jsve]

A polygon layer can be finalized while its earcut task is still waiting in a shared worker pool—for example, when a viewport changes or a progressive Arrow response is replaced before every record-batch layer finishes triangulating.

finalizeState() correctly avoids terminating an externally owned pool, but the obsolete layer’s queued task remains. It can later consume worker time and allocate or transfer geometry even though its result can no longer be displayed.

Would it be possible for the layer to retain ownership of its queued task and discard it during finalization if it has not started yet, without terminating the shared pool?

This could use the pool’s task handle, an abort signal, or another internal mechanism. The important semantics would be:

• Finalizing one layer must not terminate or disrupt a shared pool.
• Work that has not started should be removed from the queue.
• Any promise awaited by the layer must settle cleanly rather than being left pending.
• Already-running worker jobs do not necessarily need to be interrupted; cancelling those safely is a separate and harder problem.

This would complement #225: moving payload preparation inside the worker task prevents a cancelled queued job from cloning its geometry before it starts.

A possible regression test would use a one-worker pool, hold its first task open, queue triangulation for a second layer, finalize that second layer, and verify that its worker callback never runs while the first task and the shared pool continue normally.

[jsve]

One implementation detail with threads 1.7.0: QueuedTask.cancel() is not sufficient on its own.

• It removes a task that is still waiting from the queue and emits taskCanceled.
• The task completion promise only observes taskCompleted, taskFailed, and pool termination.
• Consequently, await task remains pending forever after task.cancel().

The layer therefore needs its own finalization signal in addition to calling task.cancel(). Its wait could race the pool task against a layer-owned cancellation sentinel. If cancellation wins, the update should settle without calling setState().

There is a second case to handle: if the task has already started, task.cancel() does not stop it. The layer can still settle immediately and ignore the eventual result, but the task eventual rejection must be observed to avoid an unhandled rejection.

In short, cancellation needs to do both:

1. Remove queued work where possible.
2. Independently settle and invalidate the layer asynchronous update.

[kylebarron]

First, please ensure all your written text is written by you the human, not by an LLM. If you must include LLM-generated text, use a horizontal rule (----) to separate your human text from the LLM-generated text.

[jsve]

Sorry @kylebarron I will keep this in mind going forward!

The issues and PRs you have seen from me in the past few days are a collection of bun patches we are currently applying in production. Feel free to close any that don't make sense for this package, or is not aligned with the long term vision of it. I definitely had help from GPT to proofread and make sense of my unstructured thoughts and reasoning, and apply proper formatting and references in issues and PRs bodys.

I'm mentioning the above to assure you that i haven't just thrown tokens on a random repository, but all the suggested changes are valuable for us in our current implementation and i think it might for others as well.

Hope you understand! And like I said, I'll definitely make it more clear going forward what prose is LLM written (this comment is not 😄 )!