SD-2505 - fix: avoid UI stalls with on Typo.js example

[chittolinag]

Issue

• Typo.js proofing work executed on the main thread, creating typing lag and unresolved imports for the worker bridge (./typoWorkerMessages, ./typoWorker).

Proposed solution

• Use a worker implementation so the provider compiles and runs its spellcheck logic inside a dedicated Web Worker, keeping the UI responsive.

[linear]

SD-2505 BUG: spellcheck - significant lag on load and when typing

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 02dbe3d671

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Prevent abort handler from dropping uncancelled worker checks

If a proofing batch takes longer than timeoutMs (10s default in ProofingSessionManager), this abort handler rejects immediately and removes the request from pending, but the worker keeps computing because no cancel message is sent. When the worker eventually posts its result, handleMessage drops it (if (!entry) return), so segment hashes are never updated and the same segments can keep timing out/retrying without ever producing accepted results. This regresses behavior for large/slow documents; either propagate cancellation to the worker or avoid rejecting until the worker run is actually stopped.

Useful? React with 👍 / 👎.

[caio-pizzol]

when a check takes longer than 10s, ProofingSessionManager gives up and the provider rejects — but nothing tells the worker to stop. the worker keeps running, eventually replies, and the reply gets thrown away here. next cycle, the same segments come back through and get sent to the worker again. i hit this in the browser against superdoc@next — same segmentId posted twice in a row, worker still busy from the first one. that's the same "spellcheck never settles" feel the PR is trying to fix, just via timeouts now instead of a blocked main thread. fix is to post a cancel message to the worker so it stops early.