Split toPdf() for worker-parallel page rendering

[philips]

Summary

• Implements plans/rtr-searchable-pdf-workers.md: splits toPdf() into createPdfContext (font/document setup) + addPdfPage (per-page image embed + invisible RTR text layer), so applications can render pages in parallel across Web Workers / worker_threads while PDF assembly (which needs non-clonable pdf-lib objects) stays on the main thread. toPdf() itself is now a thin wrapper and its behavior/signature is unchanged.
• Adds extractPageRenderData(note, pageNumber), exported alongside a widened toImage parameter type (IRenderableNote), so a single page's render-only data can be posted to a Worker without cloning the whole note or reconstructing a fake SupernoteX.
• addPdfPage accepts either an image-js Image or pre-encoded PNG bytes, so a Worker that already ran toImage + encodePng can hand back just bytes.
• Profiling (tests/pdf.bench.ts; one-shot breakdown recorded in the plan doc) found encodePng, not RLE decode, dominates the worker-eligible side of the work, and that pdfDoc.save() alone is ~34% of total time and inherently unparallelizable (one whole-document serialization, regardless of how pages were rendered) — so this implements render-only parallelism (Option A) and skips per-page PDF merging (Option B), per the plan's non-goals.
• Fixes relative imports in src/ to include explicit .js extensions. tsc's "bundler" module resolution allowed omitting them, but that left the built lib/ output unloadable by Node's own ESM resolver — needed here because the new worker_threads round-trip test's worker fixture (tests/fixtures/render-worker.mjs) loads lib/ directly (workers can't run .ts).
• Adds a pretest script (npm run build) so npm test reliably has lib/ built locally; CI already builds before testing.
• Documents the application-side Worker orchestration pattern in the README.

Test plan

• npm run build
• npm run lint
• npm test (21 tests across main.test.ts, pdf.test.ts, pdf-worker-roundtrip.test.ts, all passing, including the 4 pre-existing pdf.test.ts cases unmodified)
• New: toPdf() output is text-equivalent to manual createPdfContext+addPdfPage composition (backward-compat check)
• New: addPdfPage given an Image vs. pre-encoded PNG bytes produces text-equivalent output
• New: real worker_threads round trip — extractPageRenderData → structuredClone sanity check → Worker renders via toImage+encodePng → main thread decodePngs the result and byte-compares against a main-thread toImage render (byte-identical)
• npx vitest bench tests/pdf.bench.ts for the render-vs-assemble timing breakdown

[philips]

Added `tests/pdf-parallel.bench.ts`, which spawns a real 4-worker `worker_threads` pool and compares wall-clock time directly against `toPdf()`'s single-thread path — the earlier `pdf.bench.ts` only measured the render/assemble time split, not actual parallel execution.

Result on `1to10.note` (10 pages): 1.80x faster (2242ms mean serial vs. 1247ms mean parallel with a 4-worker pool), confirming the split is a real win, not just theoretically parallelizable.