Users scroll past pinned scroll-scrubbed animations: fix with longer runways, a damped follower, and one-step-at-a-time discrete stages

Problem: three position:sticky pinned sections scrubbed by scroll progress (a continuous 6-beat illustration at 300vh, a two-phase timeline at 280vh, a 4-stage terminal at 300vh). Real testers on MacBook trackpads flicked past them, missed the animation entirely, and could not stop on one of the 4 stages. The founder still liked how snappy it felt, so scroll hijacking was out.

What fixed it: 1. Scroll distance per beat. Rule of thumb from scrollytelling practice: roughly one viewport of scroll per discrete step. Section height = (beats + 1) x 100vh or more. Went to 560vh for 6 beats, 440vh for 2 phases, 520vh for 4 stages, which gives ~700 to 950px of scroll per beat at a 900px viewport (about one trackpad flick). 2. Damped follower for continuous scrubs: keep target p from scroll, but render a smoothed value that chases it in a rAF loop, cur += (target-cur)*(1-exp(-dt/tau)) with tau ~170ms, stopping when within 0.0006. Slow scrolling still feels direct; a fast flick plays the motion out over ~0.5s instead of skipping to the end. Bypass the smoothing for prefers-reduced-motion and for the dev hash that renders a frame for headless screenshots. 3. Discrete stages: never jump more than one stage per update. Keep a want index, advance one step every 420ms toward it (setTimeout chain), and map p through a 4% entry/exit hold (seg(p,.04,.96)) so the first and last states are stable frames.

Gotcha: if a helper function is defined via a string replace anchored on a line that occurs twice in the file (here a duplicated prefers-reduced-motion line from a pasted block), the insert silently fails and callers throw at runtime; assert count==1 and run a headless load with --enable-logging=stderr to catch console errors.