next.js

051e6979 - [test] Enable deploy tests for the Instant Navigation Testing API suite (#95236)

[test] Enable deploy tests for the Instant Navigation Testing API suite (#95236) The Instant Navigation Testing API suite set `skipDeployment: true`, so it only ran under `next dev` and `next start`, which never exercise the real `instant()` flow against a deployment, where the prefetched shell is served from the ISR or edge cache rather than rendered per request. This removes `skipDeployment` so the suite runs on deploy and can catch regressions that are invisible locally. Running the suite on a deployment surfaced that the `runtime params are excluded from instant shell` tests, which asserted that `/dynamic-params/unknown` keeps its param out of the instant shell, do not hold there. That route defines `generateStaticParams` (for `hello`), which makes its fallback shell upgradeable: on a deployment the first concrete navigation to a non-listed param triggers a background prerender of the upgraded shell with that param, whose result (HTML and all segments) is written into the ISR cache. Subsequent prefetches then read those upgraded segments, so the prefetch the instant shell reads already contains the resolved param and the Suspense fallback never appears. The same fallback-shell upgrade is expected under `next start`, which is meant to persist the background prerender to disk, but for reasons to be investigated separately it does not currently affect these prefetches there, so the assertion held under `next dev` and `next start` but broke on a deployment. This upgrade is correct behavior, because a non-listed route param legitimately becomes static once the route has been prerendered for it, so it is not a reliable runtime value to assert exclusion on. The exclusion tests now run against a route that defines no `generateStaticParams` and is never upgradeable (`ungenerated-params/[slug]`), so its param never enters the prefetched shell: under the instant lock the Suspense fallback is shown, and the resolved value appears only after the lock is released. The client-navigation, page-load, and hover-prefetch variants share that route with a stable param and are grouped with the existing ungenerated-params case, whose duplicate client-navigation test is removed. With the exclusion tests moved off it, the `dynamic-params/[slug]` route only serves the statically generated `hello` slug, so it is renamed to `static-params/[slug]` and continues to back the `statically generated params are included in instant shell` tests. The `runtime params are excluded from instant shell` describe now holds only the search-param cases and is renamed to `search params are excluded from instant shell`. A larger set of tests now stays skipped on deploy. Any test that drives a full-page load under the instant lock, whether a plain-anchor MPA navigation or a reload, relies on the lock re-engaging on the freshly loaded document through the prerendered-shell bootstrap (`self.__next_instant_test`), which is only embedded into the deploy-served prelude in #95222. Without it the lock engages unreliably on a deployment, so the out-of-band client fetch is not blocked and the deferred data never streams back, and these tests time out or fail. The `clears the instant cookie and serves an error when the static shell is empty` test stays skipped for a separate reason, a blocking route whose empty static shell would otherwise leave the user stuck, which #95227 fixes.