docs: place shell param-order rule with build-time shells (#101680)
## Summary
- ISR with Cache Components guide: moves the rule that shells leave
params open only from the end of the route out of "What the upgrade
produces" and into "At build time", where it describes which shells
exist. Under the upgrade section it read as a limit on the upgrade
itself, which confused a reader in
https://github.com/vercel/next.js/discussions/101644.
- Caching getting-started page: the prerendered-output bullet now says
the RSC payload is stored alongside the HTML and serves client
navigations.
## Possible follow-ups
Gaps surfaced while answering the discussion, to stack on top of this
PR:
- The general rule that the build records whether a route reads cookies,
headers, or URL data, so a prefetch is served from static output when a
runtime render can't add more UI. Today only the `navigation()` case is
covered, in "Keep the prefetch static".
- Fallback and narrower shells (`/[category]/[product]`,
`/tops/[product]`) regenerate on the `revalidate` and `expire` of the
content inside them. The docs cover only the static shell and the
concrete page.
- A segment without `generateStaticParams` produces a shared shell on
upgrade (`/shoes/[product]`), while one with it upgrades straight to the
concrete URL.
- One place that follows a navigation from static shell to App Shell to
per-link prefetch to navigation, and names the lever at each step.
<!-- NEXT_JS_LLM -->
next.js
df7104dd - docs: place shell param-order rule with build-time shells (#101680)
