Add a dwell delay for preload="viewport": cancel preloading when the link leaves the viewport before the delay expires

[nbarinov]

Problem

With preload="viewport", a route is preloaded as soon as the link intersects the
observer zone (rootMargin: 100px). The IntersectionObserver callback calls
doPreload() on the first intersecting entry, immediately. preloadDelay only
applies to intent preloading (mouse enter, touch start, focus), so there is no way
to soften viewport preloading.

On long scrollable grids this floods the API: every link that flies past during a
fast scroll kicks off its route loader, even though the user never actually saw it.

Repro

• StackBlitz: https://stackblitz.com/github/nbarinov/router-viewport-preload-repro
• Source: https://github.com/nbarinov/router-viewport-preload-repro

The page renders 200 product cards, each a <Link preload="viewport"> whose route
has a loader. A fixed panel counts loader calls, and nothing is ever clicked, so
every call is a preload. One quick scroll through the list drives the counter to
200 out of 200: every card fired its loader, including cards that were visible for
a couple of frames. The links even set preloadDelay={500}, which has no effect
for viewport preloading.

Proposal

Give viewport preloading dwell semantics:

• when the link starts intersecting, arm a timer for the configured delay
• if the link stops intersecting before the timer fires, cancel it
• when the timer fires, call preloadRoute exactly as today
• keep the observer alive for the whole mount, so re-entering the viewport arms
  the timer again (this matches the current re-fire behavior)

We are running exactly this in production as a thin wrapper around Link
(passing preload={false} down and driving router.preloadRoute from our own
observer). It is a product catalog in a Telegram Mini App: with a 500 ms dwell
the same fast flick produces zero preloads, and a short rest preloads only the
links that are actually sitting in the viewport.

API question

There are two ways to expose this, and we would like maintainer input before
implementing anything:

1. Make the existing preloadDelay / defaultPreloadDelay apply to viewport
   preloading as well. Symmetric and adds no new API, but it changes behavior for
   apps that already set defaultPreloadDelay for hover: their viewport preloads
   would suddenly become delayed.
2. Add a dedicated option (for example preloadViewportDelay), defaulting to 0
   so current behavior is preserved. Safer, at the cost of a slightly bigger API.

We lean toward option 1 with a release note, but option 2 is the safer,
behavior-preserving change. Either works for us.

Related implementation note

The viewport observer callback currently reads only the first entry of the batch.
Entries are batched per frame, so during a fast scroll a link can both enter and
leave within one frame, and the batch then contains two transitions for the same
target. The last entry reflects the actual state and should win. This is invisible
today because the callback fires the preload on any intersecting entry, but it
starts to matter once cancellation exists, so it is worth fixing as part of this
change.

Offer

Happy to submit a PR with tests once the direction is agreed. Our production
implementation (a dwell ref callback with cancel-on-exit, based on React 19 ref
cleanup) is ready to be adapted to the current link.tsx structure.

[Sheraff]

Thank you for bringing this up, it will be handled in the next release w/ #8029
We went with reusing preloadDelay for it. The use-cases feel similar enough that this doesn't warrant a separate API: both of them are "don't be too eager, it might be wasted work"

[nbarinov]

Thank you for the fast turnaround!