Give thumbnails their own cheap, low-resolution load path

[philips-clanker]

Summary

Integrates supernote-typescript#41 (merged), closing supernote-typescript#40 - the follow-up filed while debugging #154.

toImage() now accepts a scale downsample factor and decodes directly at the reduced resolution (RattaRLEDecoder.decodeAtScale) rather than decoding at full resolution and shrinking afterward - a full pageWidth×pageHeight buffer is never allocated. On a real 1404×1872 page that's a ~10MB decode (full res) vs. ~100KB (scale 10), per that PR's own measurements.

This addresses the root inefficiency behind #154's whole crash trail: the thumbnail sidebar was reusing ensurePageImage() - the exact same full-page-resolution path the main view uses - just to fill in a ~140px preview. #156's rootMargin fix and #159's debounce both worked around how often that fired, not how expensive each individual thumbnail load actually was.

Changes

• Threads an optional scale parameter through the whole rasterization path: ImageConverter.convertToImages → WorkerPool.processPages/processChunk → the SupernoteWorkerMessage sent to the Worker → toImage() itself.
• Bumped the supernote-typescript submodule to the merged commit.
• Gives thumbnails their own entirely separate state (thumbnailDataUrl/thumbnailLoadPromise) and load/evict cycle (ensureThumbnail()/evictThumbnail()) at a new THUMBNAIL_SCALE = 4 (a ~1400px-wide page decodes to ~350px - comfortably above the sidebar's own ~140px width, with headroom for higher-DPI displays), fully decoupled from ensurePageImage()/evictPageImage()'s full-resolution main-view state. A thumbnail being visible no longer implies (or requires) the main view's own image to load, and vice versa - neither shares a resolution or cost with the other anymore.

What I could not verify

Same caveat as the rest of this issue's PRs: no Obsidian/Electron/X server in my environment. Did directly verify the underlying scaled decode against a real fixture (tests/input/a5x-2.14.28.note, 1404×1872): scale: 4 correctly produces a 351×468 image. The rest (worker message plumbing, thumbnail sidebar wiring) is verified via tsc/eslint/tests and careful tracing, not by actually opening a real note.

Test plan

• npx tsc --noEmit - clean
• npx eslint src/main.ts src/myworker.worker.ts - 0 errors
• npx vitest run - 95 passed
• npm run build - clean
• Verified toImage(sn, [1], { scale: 4 }) against a real fixture produces correct output dimensions (351×468 from a 1404×1872 page)
• Manual: thumbnails still populate correctly and look right at their displayed size
• Manual: scrolling the thumbnail sidebar (slowly and quickly) through 100+ pages no longer crashes, and feels noticeably lighter/faster than before
• Manual: main view's own full-resolution image loading/zooming/saving is unaffected