Decision made based on this high tech, large sample size polling data: https://discord.com/channels/830184174198718474/867764597838184478/966981090831126559

Relies only on the existence of `.md` files to decide how to generate fallback pages rather than relying on the navigation contents as previously.

This is possible now that slugs are consistent across locales and helps for cases where a nav link isn’t for an actual page (“Installation” currently hits a redirect route for example).

Brings in some fixes for Markdown Content component

Something about how components are rendered goes wrong on build (not during dev) if we pass `Content` out of `getStaticProps` via props. Explicitly globbing the content again inside the page itself seems to fix this 🤷

See https://developers.google.com/search/docs/advanced/crawling/localized-versions#html

We tag navigation sidebar entries as “fallback” content based on if the slug exists for a given language. Previously I did this using Vite’s `import.meta.glob('../pages/**/*.md)` to grab the URLs of all pages. Although this shouldn’t load content (you need `globEager` for that), this still seemed to trigger Astro processing *all* Markdown pages. Unsurprisingly, this was slow — HMR of ~10s for a single page edit 😬

I’ve replaced the glob by recursively reading the pages directory when needed using `fs.readdir`. Avoiding globbing also means we can target *only* the relevant language instead of all pages. That brings reloads back down to 100–200ms in dev.

There is a disadvantage: if new pages are added while running `dev`, the navbar may be cached for previously visited pages and because we’re not using `glob`, Vite/Astro don’t know we’re depending on files, so won’t invalidate that cache. Not sure if there’s a workaround? But still, this solution seems preferable to waiting 10 seconds each time you make an edit.