Expose prefetch config for sidebar links in nextra-theme-docs

Is your feature request related to a problem? Please describe.

nextra-theme-docs hardcodes prefetch={false} on every sidebar <Anchor>, which disables both viewport and hover-on-intent prefetching. There is no theme config or prop to opt back in.

Relevant lines in packages/nextra-theme-docs/src/components/sidebar.tsx (visible in the compiled output at dist/components/sidebar.js:130 and :238):

<Anchor href={item.route} prefetch={false} ... />

For docs sites where the RSC payload per page is non-trivial (~100 KB+) and visitors are far from the edge, every sidebar click pays the full edge round-trip — easily 300–500 ms of perceived navigation lag, even though the route bundle is tiny. Next.js' default Link prefetch behavior (or the HoverPrefetchLink pattern) would eliminate this, but the hardcoded false blocks both.

The Anchor component itself already forwards prefetch to next/link — see packages/nextra/src/client/mdx-components/anchor.tsx. So the prop plumbing is in place; it just isn't surfaced through theme config.

Describe the solution you'd like

A new option on the existing sidebar config object that's forwarded directly to <Link prefetch={...}>:

<Layout
  sidebar={{
    prefetch: false | true | null  // forwarded to <Link prefetch={...}>
    // …existing options
  }}
>

• Default: false (preserves current behavior — no breaking change).
• null: Next.js default — static routes prefetched, dynamic routes prefetched into router cache on hover/in-view.
• true: always prefetch.

Ideally the same option (or a parallel one) would also apply to breadcrumb and pagination links, which hardcode prefetch={false} the same way.

Describe alternatives you've considered

Consumers can patch this client-side by attaching a mouseover / focusin listener at the document level and calling router.prefetch(href) for sidebar anchors (the HoverPrefetchLink pattern applied via DOM delegation). That works but couples app code to theme markup (aside selector) and silently breaks if the sidebar HTML structure changes in a future Nextra release. A first-class config option is cleaner and survives internal refactors.

Forking the theme is also possible but pulls in maintenance cost on every Nextra upgrade.

Additional context

Happy to send a PR if the API shape is acceptable — wanted to align on the option name / shape (and whether breadcrumbs and pagination should share the same flag or get their own) before opening one.