docs: add experimental advanced routing reference page

[matthewp]

Description (required)

Documents the upcoming experimental.advancedRouting flag.

For Astro version: 6.2. See astro PR #16366.

[netlify]

✅ Deploy Preview for astro-docs-2 ready!

Name	Link
🔨 Latest commit	571ef48
🔍 Latest deploy log	https://app.netlify.com/projects/astro-docs-2/deploys/69f1233ec9c5a400080a10eb
😎 Deploy Preview	https://deploy-preview-13792--astro-docs-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[astrobot-houston]

Lunaria Status Overview

🌕 This pull request will trigger status changes.

Learn more

By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.

You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File	Note
en/reference/experimental-flags/advanced-routing.mdx	Localization added, will be marked as complete.

Warnings reference

Icon	Description
🔄️	The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

[ArmandPhilippot]

Thanks Matthew, the wording looks good to me! No suggestions to improve that, only for the formatting:

• We usually don't put the arguments in the headings (ie. middleware() instead of middleware(state, next)). This helps make the links easier to parse when sharing them: #middleware instead of #middlewarestate-next
• I think an API block for the methods is also helpful since some of them have different arguments or different return types.

I also noticed a few em dashes. We usually don't use them in docs. I don't know if we want to stay consistent with this or not. I don't have a strong opinion.

Question: Do we need a section for ContextProvider?

I see that the FetchState types often refer to create and finalize. Maybe it would be helpful to document it so we can link to ContextProvider.create() and ContextProvider.finalize(). I think this helps users navigate easily to between related sections.

[yanthomasdev]

Thanks @matthewp, just adding a few suggestions to remove all these emdashes that are not necessary, and then LGTM

[yanthomasdev]

I'll say we should keep it consistent without emdashes.

Suggested change

	The [`astro()` handler](#astro) is the simplest way to add pre- or post-processing around the full pipeline. When you need to insert logic *between* specific stages — for example, running custom code after actions but before page rendering — compose the individual handlers instead:
	The [`astro()` handler](#astro) is the simplest way to add pre- or post-processing around the full pipeline. When you need to insert logic *between* specific stages, such as running custom code after actions but before page rendering, compose the individual handlers instead:

[yanthomasdev]

Safe to remove the subheading of the subheading 😅

Suggested change

	### Using `astro()` — the simplest approach
	### Using `astro()`

[yanthomasdev]

Suggested change

	// Custom pre-processing — runs before any Astro handler
	// Custom pre-processing, runs before any Astro handler

[yanthomasdev]

Suggested change

	// Custom post-processing — runs after Astro renders
	// Custom post-processing, runs after Astro renders

[yanthomasdev]

Suggested change

	For many use cases — adding auth guards, request logging, custom headers — `astro()` is all you need.
	For many use cases, such as adding auth guards, request logging, and custom headers, `astro()` is all you need.

[yanthomasdev]

Suggested change

	Dispatches the request to the matched Astro route (page, endpoint, or fallback). This is the core rendering handler — most custom pipelines will include it.
	Dispatches the request to the matched Astro route (page, endpoint, or fallback). This is the core rendering handler, and most custom pipelines will include it.

[yanthomasdev]

Suggested change

	Runs Astro's middleware chain (from `src/middleware.ts`). The `next` callback is called at the bottom of the chain to produce the response — typically by calling `pages()`:
	Runs Astro's middleware chain (from `src/middleware.ts`). The `next` callback is called at the bottom of the chain to produce the response, typically by calling `pages()`: