fix(view): one wheel notch stops within about 0.2 s in every view (#522)

[DutchSailor]

Closes #522.

What happened

In single-page mode the wheel added velocity that decayed by a fixed factor per animation frame. The run-out therefore depended on the frame rate: measured with a fake clock, one notch (deltaY 100) kept moving for 285 ms at 144 fps, 683 ms at 60 fps and about 2 seconds at 20 fps, which is what a heavy vector page renders at. It also travelled about 207 px instead of 100, and a touchpad swipe got the same floaty run-out. The continuous, book and side-by-side views left the wheel to the browser, so the views behaved differently.

What this changes

• New pure module js/pdf/wiel-scroll.js, shared by every view:
  • converts deltas to pixels (lines, pages, Shift+wheel);
  • tells a mouse-wheel notch from touchpad input;
  • lets a notch travel exactly its distance with a short ease-out of 180 ms that runs on time, not on frames;
  • adds quick notches to what is still to come, without lag or overshoot; a notch back reverses at once, also right after hitting the scroll edge;
  • keeps the sub-pixel remainder and stops as soon as something else scrolls (scrollbar, keys, a jump to a page).
• pdf-viewport.js: the friction velocity is gone; the render loop plays the helper.
• navigation-events.js: single page, continuous, book, side by side and blank documents use the same helper for mouse-wheel notches; touchpad and fine wheel input stay 1:1 (in the scrolling views the browser keeps them). Inputs and elements that scroll themselves keep their own wheel.
• Smooth jumps (go to page, search result, annotation list) are not cancelled by a wheel run-out that is still going.
• Unchanged: page flipping at the page edge, Ctrl+wheel and pinch zoom, the compare view.

Behaviour change on purpose: in single-page mode one notch now moves 100 px, like the other views, instead of the earlier ~207 px. If a larger step is wanted, it is one factor in one place.

Verification

• js/pdf/wiel-scroll.test.mjs, 22 tests with a fake clock. They were first run against a copy of the old algorithm behind the same calls (14 failed for the reported reasons, e.g. still moving at 285 ms, 207 px instead of 100, five notches 1040 px instead of 500).
• New measurements: one notch settles after 181-200 ms at any frame rate and travels exactly 100 px; five notches 50 ms apart travel exactly 500 px and settle 183 ms after the last.
• An adversarial review found three defects (a notch back after the scroll edge partly lost, in two variants; a run-out cancelling a smooth jump); all fixed test-first.
• npm run test:unit 2613 passed, 0 failed; npx vite build and npm run typecheck green.
• Synthetic wheel input in automation does not reproduce native behaviour reliably, so the feel needs a manual check in the real window: one notch on a heavy drawing, fast spinning then stopping, page flips at the edge, the same feel in every view, precision touchpad, Shift+wheel, Ctrl+wheel.

🤖 Generated with Claude Code