Config Redirects Erroneously Match _Next/Data Requests When Middleware.Ts Is Present, Breaking Client-Side Navigation

In resolve-routes.ts, the middleware_next_data route normalizes _next/data URLs to their original path only when fsChecker.getMiddlewareMatchers()?.length is truthy. This normalization occurs before config redirects are processed, so normalized paths (e.g., /type/details) match config redirects. Without middleware, normalization is skipped and config redirects never match _next/data URLs. The presence of middleware changes the pipeline order, leading to inconsistent behavior.

1. Create a Next.js app with middleware.ts and a config redirect from '/:type/details' to '/'. 2. Start the app and navigate to /start. 3. Click a link that triggers client-side navigation to a page using getStaticProps. 4. Observe that routeType from getStaticProps is undefined because the data request for the page is redirected to the wrong route. 5. Remove middleware.ts and repeat: routeType is correctly 'foo'.

This change could affect edge cases where users intentionally redirect _next/data requests (extremely rare). It is recommended to test thoroughly with middleware and redirects. If any regression appears, roll back this patch and use the manual workaround of adding a missing header condition ({ type: 'header', key: 'x-nextjs-data' }) to each redirect in next.config.js.