[0.3.0-S0] Prove PdfTool supervisor + loop-pdf-worker isolation for untrusted open/preflight

[cursor]

Context

ADR: Isolate untrusted PDF processing in a worker process

Linear: https://linear.app/mbx2/issue/MB-683/030-s0-prove-pdftool-supervisor-loop-pdf-worker-isolation-for

Untrusted PDF bytes must not be parsed, decoded, rendered, preflighted, or repaired in the same process as LoopEditor (or any other privileged host). Prove isolation first on the PdfTool supervisor + loop-pdf-worker path for the untrusted open/preflight surface.

Acceptance criteria (0.3.0-S0)

• A dedicated worker process (loop-pdf-worker, or PdfTool in worker mode) owns LoopLibCore for untrusted open/preflight jobs; the PdfTool supervisor stays in a separate process.
• Worker IPC is an allowlist, not a general RPC. For this slice the allowlist proves at least: open, preflight, cancel, ping (reuse existing PdfTool JSON / workload envelopes + artifact/revision identity).
• The worker never initializes Sentry or crashpad (no customer-heap minidumps from hostile PDFs).
• Linux sandbox on the worker: no network; FS restriction (Landlock or equivalent) to input, private temp, and output dir; RLIMIT/CPU/RSS aligned with the resource envelope. A missing platform sandbox is a build/packaging failure for release workers, not a warning.
• Worker crash, hang, budget kill, or sanitizer SIGSYS is a failed job with typed incomplete / unavailable — supervisor stays up, never PASS, never a partial write published as the artifact; host can kill/replace the worker without restarting the supervisor.

Non-goals for this issue

Full Editor migration, render-page / transform / sanitize allowlist expansion beyond prove-open/preflight, rewriting LoopLibCore, or agent execution authority.

References

• Notion ADR: https://app.notion.com/p/3dc9cb079ddb812b9f1fd668196818c6
• Linear: MB-683