[zumbrunn]

Fixes #60

• Stop revoking the worker's blob URL right after new Worker() (races Deno's async module load; crashed boot on 0.35.0).
• Add a worker error handler: a load/runtime failure logs and disables the watchdog instead of exiting the process.
• Tests: worker-load-failure child process survives with "watchdog disabled"; guard against reintroducing revokeObjectURL. Changelog entry added under Unreleased.

Note: I couldn't reproduce the original race locally (Deno 2.9.5, with and without --cpu-prof), so the load-failure test covers the new error path rather than the race itself.

🤖 Generated with Claude Code

[zumbrunn]

Review: the fix is right, and the bug is mine (the watchdog, #51).

• Not revoking the blob URL removes the race with Deno's asynchronous module-worker load; one tiny blob per process lifetime is harmless.
• The error handler is the important half: a load failure or a runtime throw in the worker degrades to "watchdog disabled" plus a log line instead of exiting the process the watchdog is meant to protect. preventDefault() + stop() is the right order.
• The load-failure test (a Worker subclass pointing at a throwing data URL) exercises that path for real. The source guard against revokeObjectURL is brittle, but it is a cheap tripwire for exactly this regression.

Why I never saw it: my tests and live runs happened on a fast machine, where the load always finished before the revoke. Slow startup (--cpu-prof, a small VPS) makes the race deterministic, which matches the 5/5 crash in the report.

CI note: scaffold-smoke-test is red here with Could not find version of '@dune/core' that matches '^0.35' because 0.35.0 is still inside Deno's 24 h minimum-dependency-age window; it should clear by itself. check and test pass. I didn't dig into pin-drift.

One thing worth watching separately: boot on flex is ~77 s and the watchdog's startup limit is 120 s. #62/#63 and plugin-pdf#6 take ~37 s off that, which is why they matter beyond speed.