Fix dev shell validation for novel parameter values
## 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:
```ts
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)
<!-- NEXT_JS_LLM -->
