Fix dev shell validation for novel parameter values

[gnoff]

Summary

Fix Cache Components development validation so it checks the most-specific parameter shape produced by generateStaticParams, regardless of the literal parameter values in the request.

This is a standalone fix for existing behavior, with no experimental matching API or feature flag. It forms the bottom of the parameter-matching stack. #97393 builds on this separation to let explicit fallback directives choose an earlier validation boundary, so this fix can land without committing to the new API.

Why

The dev server currently chooses fallback parameters by matching the requested URL against the generated paths. That is appropriate for staging the foreground response, but that same selection also reaches background static-shell validation. A novel value therefore causes validation to check a more generic shell than the build requires.

For /[top]/items/[bottom], suppose generateStaticParams returns:

return [{ top: 't1' }]

The build validates /t1/items/[bottom]: top is available, while bottom remains dynamic. A dev request for /t2/items/b2 should exercise the same shape using its actual top: 't2' value. It should not require the shell to work with both top and bottom unknown.

Generated example	Dev request	Unknown parameters during static-shell validation
{ top: 't1', bottom: 'b1' }	/t2/items/b2	None
{ top: 't1' }	/t2/items/b2	bottom
No examples	/t2/items/b2	top, bottom

This restores the value-independent validation semantics that were lost when #95066 made foreground staging value-sensitive. It does not revert that foreground staging change.

Changes

• Select the smallest fallback-parameter set across all generated paths for validation, separately from the per-URL set used by the foreground render.
• Pass that validation shape through dev-only request metadata.
• When the two shapes differ, construct a separate validation context and request store. Do not reuse Flight chunks produced with the foreground parameter shape; use the existing background validation render instead.
• Require an explicit render context at every dev payload call site, rather than defaulting to a captured foreground context or introducing a separate validation wrapper.
• Keep production rendering, build output, cache-miss routing, and the foreground dev response unchanged.
• Strengthen the existing no-API fixture to wait for background validation before asserting success. Restore the novel-top error expectation to the page that reads the genuinely dynamic bottom, rather than the layout that reads top.
• Limit this fixture to static-shell validation so automatic navigation-boundary insights do not obscure the behavior under test.

Verification

• Reproduced two failing regression cases against the unchanged baseline, then passed the suite with the fix.
• CI=1 pnpm build-all (uses the installed native package)
• pnpm --filter=next types
• ESLint and Prettier for the changed files
• pnpm test-dev-webpack test/development/app-dir/cache-components-dev-fallback-validation/cache-components-dev-fallback-validation.test.ts
• pnpm test-dev-turbo test/development/app-dir/cache-components-dev-fallback-validation/cache-components-dev-fallback-validation.test.ts
• pnpm test-dev-webpack test/development/app-dir/cache-components-dev-warmup -t 'mixed static and fallback params resolve in the correct phase' (24 checks across eight configurations; also passed against the unchanged baseline)

[github-actions]

Failing test suites

Commit: 36e32f2 | About building and testing Next.js

pnpm test-dev test/development/app-dir/instant-navs-devtools/instant-navs-devtools.test.ts (job)

• instant-nav-panel > history traversals > re-arms the capture when navigating back from a captured SPA navigation (DD)

Expand output

● instant-nav-panel › history traversals › re-arms the capture when navigating back from a captured SPA navigation

locator.waitFor: Timeout 60000ms exceeded.
Call log:
  - waiting for locator('[data-testid="dynamic-skeleton"]') to be visible

  278 |     await browser
  279 |       .locator('[data-testid="dynamic-skeleton"]')
> 280 |       .waitFor({ state: 'visible' })
      |        ^
  281 |     await browser
  282 |       .locator('[data-testid="param-skeleton"]')
  283 |       .waitFor({ state: 'visible' })

  at waitFor (development/app-dir/instant-navs-devtools/instant-navs-devtools.test.ts:280:8)
  at Object.expectTargetPageSpaShell (development/app-dir/instant-navs-devtools/instant-navs-devtools.test.ts:834:13)