### What?
Flips the default `experimental.instantInsights.validationLevel` from
`'manual-warning'` to `'warning'` so Cache Components apps get
instant-navigation validation across all pages by default.
### Why?
`'manual-warning'` only validates pages that explicitly export
`unstable_instant`, so apps see nothing unless they opt in. `'warning'`
is what users have been turning on manually to actually see the feature
(`v0`, `vercel-site`).
### Test coverage
- Unit: `instant-config-normalization.test.ts` pins the framework
default at `'warning'`.
- Integration: new `instant-validation-level-default/` fixture (no
`instantInsights` in config) asserts implicit dev validation fires, and
that build is unaffected.
### Collateral test fixtures
Tests whose intent is unrelated to instant validation
(router-autoscroll, owner-stack, hmr-iframe, next-image,
server-source-maps, etc.) now hit new redboxes/console warnings because
their fixtures incidentally use dynamic data. Each opts out with
`experimental: { instantInsights: { validationLevel: 'manual-warning' }
}` in `next.config`.
### Open question
With no `'off'` / `'info'` tier today, silencing Insights after this
change requires setting `validationLevel: 'manual-warning'`. Is that
acceptable? Should we inform of this anywhere?
<!-- NEXT_JS_LLM_PR -->
These functions can be dynamic however in this mode we are trying to
recover on the client so there is little point in attempting to resolve
the http error recovery metadata since it might block us producing a
shell. We now exclude these from the errore recovery RSC payload since
we will recover the metadata on hydration in the browser.
Effectively
Relands #93988
Reverts #92231
Prerendering the notFound loaderTree turns out to not be the correct
behavior in many cases. The original motivation of 92231 as to solve the
connection closed problem caused by statically prerendering an
incomplete HTTP event like notFound() when cacheComponents is enabled
because it would leave holes in the inlined flight data that never
resolved and led to reported errors on hydration.
This change now continues to fork the CC behavior of the error handler
but it treats the error page as a resumable page so fresh hydration data
is generated if it wasn't able to be entirely static.
This is good for correctness but it also means the page is not going to
statically prerender the notFound UI. This will be handled in a followup
---------
Co-authored-by: Hendrik Liebau <mail@hendrik-liebau.de>