Make the default link prefetch effective on mobile (viewport, not just touchstart)

[vivek7405]

Problem

The client router's default link prefetch uses the intent strategy: it warms the next page on hover / focus / touchstart (router-client.js). On mobile this gives little to no benefit: there is no hover, and touchstart fires essentially at tap time, so the prefetch races the navigation instead of front-running it. The fast-by-default promise effectively does not hold on touch devices.

Design / approach

Research and ship a prefetch strategy that actually helps on mobile, without regressing desktop or over-fetching on metered connections:

• Viewport / visible prefetch (Quicklink / SvelteKit hover-plus-viewport model): prefetch links as they enter the viewport, throttled and gated on navigator.connection (skip on save-data / 2g), the most reliable mobile signal.
• Consider making the DEFAULT strategy mobile-aware (viewport on touch / no-hover, intent on pointer devices) rather than a single intent default, keeping the per-link data-prefetch override.
• Respect prefers-reduced-data / save-data, a concurrency cap, and the existing prefetch cache + mutation eviction.
• Keep it build-free and progressive-enhancement-safe (no behavior change with JS off).

Prior art: Quicklink, Next.js <Link prefetch>, SvelteKit data-sveltekit-preload-data="viewport", Astro prefetch viewport.

Acceptance criteria

• Links are prefetched on mobile with a real head-start before tap (viewport or equivalent), not only at touchstart.
• The default is mobile-effective; data-prefetch per-link overrides still work.
• Honors save-data / reduced-data + a concurrency cap; no over-fetch.
• Browser/e2e coverage on a touch-emulated viewport.
• Docs (agent-docs/advanced.md client-router prefetch section) updated.

[vivek7405]

Direction: device-adaptive default (hover on pointer, viewport on touch)

Preferred approach for the default prefetch: make it adaptive to the input modality rather than a single strategy.

• Pointer / laptop / desktop (a real hover capability): keep intent (prefetch on hover / focus). It is precise and cheap, and a mouse gives a genuine head-start before the click.
• Touch / mobile (no hover): switch the default to viewport (prefetch links as they scroll into view), since touchstart fires too close to the tap to help.

Detect the modality with matchMedia('(hover: hover) and (pointer: fine)') (hover-capable pointer) vs (hover: none) / (pointer: coarse) for touch, not a user-agent sniff. Still honor save-data / reduced-data, a concurrency cap, and the per-link data-prefetch override (which always wins over the adaptive default). Keep touchstart as an additional warm on touch (it is still a small win for the link actually being tapped), but viewport is what makes mobile fast.

[vivek7405]

Layering + a declarative (no-JS) path

Two refinements:

1. Hover prefetch is the always-on baseline. Whatever the adaptive default does, the intent (hover / focus) layer keeps working on pointer devices regardless. If the viewport / adaptive logic fails to apply (an old browser, an observer that never fires, a feature-detect miss), the hover layer is still there, so we never regress to no-prefetch on desktop. Treat hover as the floor and viewport as the mobile upgrade, not a replacement.

2. Prefer a DECLARATIVE prefetch where possible (better PE). All the imperative strategies (hover, viewport, touchstart) need the page's JS to run, so with JS off there is no warming at all (navigation still works, just cold). The progressive-enhancement-friendlier option is the browser's own declarative speculation:

   • Speculation Rules API (<script type="speculationrules"> with prefetch / prerender, eagerness: moderate ~ hover-like, conservative ~ tap-like): the BROWSER speculates from a JSON ruleset, so it does not depend on our client router running, degrades safely where unsupported, and even covers a full-page navigation (not just our soft-nav fetch). This is the closest thing to "prefetch without our JS".
   • <link rel="prefetch"> in the head is the older declarative fallback, but it is eager (warms listed links unconditionally), so it needs a sane cap.
     Investigate emitting speculation rules from the router/SSR as the default warming mechanism, with the JS hover/viewport layer as the enhancement on top (and as the fallback where speculation rules are unsupported). Net: declarative-first for PE, imperative hover/viewport as the upgrade.