fix(compression): pass a URL object when spawning the LLMLingua worker

[anhtahaylove]

ensureWorker() called new Worker(pathToFileURL(absoluteWorkerFile).href, { execArgv }), which passes a string. node:worker_threads treats a string argument as a filesystem path and requires it to start with ./ or ../; only a URL instance is interpreted as a file: URL. So the "file://..." text was looked up literally as a relative path and the spawn threw ERR_WORKER_PATH.

The failure was silent. pump() wraps ensureWorker() in a bare catch {} and fails open, so every compression call quietly degraded to a passthrough while still reporting success — the worst shape for this bug, since nothing in the logs or the response says compression did not happen.

Confirmed against a real Worker on Node 24, isolated from this codebase:

href string -> ERR_WORKER_PATH
URL object  -> OK

The change

One argument: drop .href and pass the URL object.

pathToFileURL stays — the sibling test llmlingua-worker-resolution.test.ts asserts this file never touches import.meta.url or createRequire (both die in the standalone webpack bundle), and pathToFileURL is a pure path→URL converter with neither dependency. Passing the raw path instead would also work on Node, but the URL form is what keeps spaces and non-ASCII in the install path unambiguous.

Test

tests/unit/compression/llmlingua-worker-spawn-12822.test.ts asserts the source does not spawn with .href, and separately proves the runtime contract by spawning both spellings against a real worker file — so it stays honest if the call is ever reshaped rather than just matching text.

Verification

llmlingua-worker-spawn-12822 + llmlingua-worker-resolution + llmlingua-failopen   21 passed
npx tsc -p tsconfig.typecheck-core.json --noEmit    clean
npx eslint <changed files>                           clean

Fixes #12822

[anhtahaylove]

Note on the checks here: the workflows are sitting in action_required because this is my first PR to this repo, so GitHub holds them for maintainer approval. The three green checks shown (Mergify, semgrep) are the ones that run without it — the test and typecheck jobs have not run yet. Approving the workflow run will give you the real signal.

Locally on Windows 11 / Node 24.19.0: tsc -p tsconfig.typecheck-core.json --noEmit and eslint are clean on the changed files, and the touched suites pass. The 5 failures in the full tests/unit/compression/** run are pre-existing RTK cases that reproduce on a clean release/v3.8.51 checkout with my changes stashed.