Background

Since #24944 a prerendered shell never carries trace context, so a visitor of a cached page (a runtime-generated [id] shell, an ISR page, a fully static page) gets a pageload in its own trace with no server span. That is correct, but in Sentry it looks like missing server instrumentation. The user has no way to tell "nothing ran on the server for this visit" from "the server side is broken".

What this ticket does

Give the pageload a signal that the document came from a cached shell.

1. Server: while Next.js prerenders a document (the prerender route (app) span is active, see NextSentryPropagator), inject a marker meta tag instead of nothing, for example sentry-shell with a value like prerendered. It goes through experimental.clientTraceMetadata like the trace tags, so it needs to be added to that list in withSentryConfig.
2. Client: if the marker is present and no sentry-trace tag arrived, set an attribute on the pageload span that says the document was served from a cached shell. Agree on the attribute name with the conventions repo first.
3. Product: surface the attribute in the trace view so a pageload without a server span can say "served from cache" instead of looking incomplete.

Optional

The marker could also carry the trace id of the request that generated the shell, which the client would turn into a cache_origin span link, never into a parent. That restores the link that #24944 dropped. Only worth it if the product can render it.

Must still hold

The client must never continue the marker as a parent. The two hard requirements from #24298 (no inherited sampling decision, no sibling pageloads) stay intact because the marker is not trace context.