Hoist resolved pathname into app page route match (#99259)
This PR was authored by codex but I'll share the motivation here in my
own words. In an effort to improve the architectural underpinnings of
Next.js we need to move away from a request/response dominated interface
for rendering in Next.js. The legacy of this style is code that in some
cases targets a fake Request or Response object even in cases where we
are prerendering and no such objects actually exist. This PR adds a new
concept of RouteMatch which seems overkill for only containing the
resolvedPathname however we will be migrating more properties out of
catchall context such as renderOpts and other request local context into
more semantically meaningful packaging.
## Summary
Introduce a required `RouteMatch` containing the route-prepared
`resolvedPathname` and pass it explicitly through the Node, Edge, direct
server, and static export app-page render entrypoints.
The type is owned by the app-page route-module handler boundary rather
than app-render. `resolvedPathname` is no longer written to or read from
request metadata, preventing downstream code with request access from
depending on that side channel while preserving the existing
delimiter-safe pathname representation.
## Verification
- `pnpm prettier --with-node-modules --ignore-path .prettierignore
--write <changed files>`
- `npx eslint --config eslint.config.mjs --fix <changed files>`
- `git diff --cached --check`
- Source grep confirming there are no `resolvedPathname`
request-metadata reads, writes, or fields
- Could not complete: `pnpm --filter=next types` (this fresh worktree
lacks per-package dependencies and compiled declarations; the check
failed broadly on unrelated missing modules)
<!-- NEXT_JS_LLM -->
