Evict scrolled-away pages' images instead of only loading lazily

[philips-clanker]

Summary

Fixes #154 - a 100-page note still crashed on an iPhone 13 mini around page 14-20, even after #151's lazy loading. That fix only bounds when a page's image loads (on scroll-near, not upfront) - it never releases anything, so memory still grows monotonically with how many pages you've scrolled past, not how many are actually near the viewport. On a long enough document, that's still unbounded.

Update: also fixes the same crash reproduced by scrolling the thumbnail sidebar alone (reported separately) - see "Thumbnail sidebar" below.

Changes

• New evictPageImage(), called from the same pageObserver that already triggers lazy loading: once a page's container leaves the rootMargin-extended viewport, its ImageBitmap is explicitly .close()'d and its canvas backing store shrunk to 1x1. Scrolling back re-triggers ensurePageImage() exactly as if the page had never loaded (both imageBitmap and imageLoadPromise reset to null).
• Fixed a related gap this exposed in drawPageImage(): it resized every page's canvas backing store unconditionally. commitZoom() calls it for every page on every zoom change - so touching zoom on a long document would reallocate a full-size backing store for every page regardless of load state, undoing the lazy-loading memory benefit immediately. Split so CSS (layout) size still always updates for every page (scroll position / page-anchor links depend on correct page heights even for unloaded pages), but the backing store itself only resizes when there's an actual image to draw.
• Text layers (search/selection) are deliberately left alone - much lighter than a decoded bitmap/canvas, and losing search highlights on scroll-past would be a worse trade for a small memory saving.

Thumbnail sidebar

The sidebar scrolls independently of the main view, so it could reproduce the same crash on its own (toggleThumbnails() used to eagerly load every page's image the moment it opened at all, regardless of how many thumbnails were actually visible). Added a second IntersectionObserver (thumbObserver), scoped to the sidebar's own scroll container, that lazily loads/evicts thumbnails the same way. Since a page can be near the viewport in one of the two views while far from it in the other, PageRenderState now tracks visibleInMainView/visibleInThumbnail separately, and eviction only fires once both are false - so scrolling just one view doesn't evict a page the other still has visible. evictPageImage() also now clears the thumbnail <img>'s own src, since it decodes/caches its own copy independent of the main canvas.

What I could not verify

Same caveat as #151: no Obsidian/Electron/X server available in my environment, so this is verified by tsc/eslint/the existing test suite and a careful manual trace (zoom via commitZoom, initial layout sizing, goToPage, thumbnails), not by actually scrolling a 100-page note on a real device. Please verify on the actual reported scenario (a 100-page note, iPhone 13 mini or similar - both scrolling the main view and scrolling the thumbnail sidebar) before considering this closed - that's the one thing I can't substitute for here.

Test plan

• npx tsc --noEmit - clean
• npx eslint src/main.ts - 0 errors
• npx vitest run - 95 passed
• npm run build - clean
• Manual: scroll through a 100+ page note on a memory-constrained device past page 20 without a crash
• Manual: open the thumbnail sidebar on the same long note and scroll through it without a crash
• Manual: zoom in/out on a long document after scrolling partway through - no crash, and pages already scrolled past still redraw correctly if scrolled back to
• Manual: page-anchor link / thumbnail click-to-jump / page-jump input still land on the correct page even deep into a long, partially-scrolled document