Fix #154: memory blowup and freezes when viewing/exporting long notes

[philips-clanker]

Summary

Squashed version of #166 (kept open for reference/history) with the full investigation trail summarized below. Fixes issue #154.

Depends on philips/supernote-typescript#42 (submodule) — needs to merge first, or at least stay pushed, for this branch's submodule pointer to resolve cleanly long-term.

The final fix

• Lazy-loads main-view page images and thumbnails via IntersectionObserver, evicting whichever have scrolled out of view — memory is now bounded by "how many pages are near the viewport right now," not by how many have been scrolled through in total.
• The Worker pool sends only the page(s) actually requested to a Worker, never the whole parsed note — previously every worker ended up holding a full copy of the entire document, the single largest contributor to the reported memory growth.
• Fixed a race condition where a page's image could finalize and get stuck "loaded" forever if the page scrolled back out of view mid-decode.
• Reduced the Worker pool from navigator.hardwareConcurrency (8-9 workers) to a fixed 2 — the peak during a fast scroll scales with how many workers can be simultaneously mid-growth at once, so this was the actual lever for the peak.
• Tears down the whole Worker pool after 2s of inactivity, reclaiming its resting memory (~200MB); recreated lazily, and never mid-flight.
• Debounced both the main-view and thumbnail-sidebar load triggers, so a long-distance jump (e.g. a search match 100 pages away) doesn't rasterize every page it flies past on the way there.
• Thumbnails are no longer evicted at all (cheap enough now that they're downscaled) and get a generous prefetch margin — also fixes a "broken image" icon bug the old evict-on-scroll-away behavior caused.
• PDF export: caps how many pages get embedded per pdf-lib batch, correctly alpha-composites each page toward white before embedding, and runs the entire rasterize-embed-save sequence inside a dedicated Worker, since pdf-lib's own embedPng()/save() are genuinely expensive (confirmed ~1.7GB / 10+s for a 100-page note) no matter how the input is prepared.

Things attempted while locating the final fix

• Capping devicePixelRatio and using a zoom-aware rasterization scale to shrink canvas memory — disproven by direct testing (memory unaffected).
• Destroying the previous pdf.js document on file switch — a real but minor fix, not the primary driver.
• Chrome heap-snapshot/heap-timeline analysis (custom parsing scripts) to rule out a JS-heap leak, since canvas/ImageBitmap memory is invisible to the JS heap profiler.
• Temporary DevTools-console toggles to bisect the PDF text layer vs. the image layer, isolating the image/Worker rasterization pipeline as the actual cause.
• Periodically recycling (terminating/recreating) Worker instances after N calls, to bound per-worker internal growth — confirmed working, but later measured to make no real difference once the pool-size reduction and idle teardown were in place, so removed rather than kept as unjustified complexity.
• Dropping the PNG alpha channel outright before PDF embedding instead of properly alpha-compositing it — shrank memory/time but produced a black-background PDF (background pixels are packed as black with alpha 0, not white), fixed by compositing toward white instead.

Test plan

• tsc --noEmit, eslint, vitest run (95 tests) all pass
• supernote-typescript's own test suite (48 tests, including new coverage for the alpha-compositing fix) passes
• Confirmed on real devices across the investigation: peak memory during a full scroll through a 100+ page note dropped from 1.5GB+ to well under 400MB; PDF export no longer freezes the UI or produces a corrupted (black-background) file