Next.js Route Segment Config (revalidate) is not mapped to Nitro routeRules (SWR)

[AhmedElBanna80]

Describe the bug

In standard Next.js, using Route Segment Configs like export const revalidate = 10 enforces a specific cache lifetime for a page or layout.

When building an application with vinext build, this config is currently ignored and not forwarded to the generated Nitro output. As a result, pages configured with revalidate fall back to fully dynamic execution on every request because Nitro's .output/nitro.json is missing the corresponding routeRules.

Expected behavior

When vinext encounters export const revalidate = X in a page.tsx or layout.tsx, it should automatically extract this and map it to the corresponding Nitro SWR route rule in the final Nitro configuration, allowing the Nitro server/edge runtime to accurately cache the responses natively.

For example, export const revalidate = 10; in /cache-tests/time-based/page.tsx should generate the following in Nitro:

"routeRules": {
  "/cache-tests/time-based": {
    "swr": 10
  }
}

Reproduction

1. Create a page with export const revalidate = 10; and a Date.now() output.
2. Build with vinext build.
3. Start the .output/server/index.mjs Nitro server.
4. Load the page multiple times.
5. Observe: The timestamp changes on every single reload, bypassing the 10-second cache configuration entirely.

Workaround

Currently, developers must manually wrap logic inside unstable_cache(..., { revalidate: 10 }) down at the component level to correctly trigger the underlying CacheHandler in vinext, completely bypassing the top-level Route Segment Config paradigm.