The `isResponsePartial` value from `cacheData` (set by `processFetch`)
defaults to `true` when no marker byte is found. This is correct for
navigation requests (conservative default), but wrong for Full and
LoadingBoundary prefetches which are by definition complete.

Before the `processFetch` refactoring, the prefetch path only read
`isResponsePartial` from `stripIsPartialByte` for PPRRuntime, and
defaulted to `false` for other strategies. The refactoring changed it to
always read from `cacheData`, which overrode the correct `false` default
with an incorrect `true` for non-PPRRuntime strategies.

Fix: only use `cacheData.isResponsePartial` for PPRRuntime prefetches;
default to `false` for Full and LoadingBoundary.

Replace the `isResponsePartial` boolean in
`writeDynamicRenderResponseIntoCache` and `writeSeedDataIntoCache` with
a three-state `ResponseCompleteness` enum that distinguishes:

- `Partial`: segments have dynamic holes (static stage responses,
  PPRRuntime prefetches with `~` marker, postponed responses)
- `Complete`: all segments are complete, but the head may still be
  partial per the server's flag (Full/LoadingBoundary prefetches)
- `FullyStatic`: server explicitly marked the response as fully static
  (marker byte `#`) — both segments and head are complete

The boolean conflated two independent concerns: segment partiality and
whether the server's `isHeadPartial` flag can be overridden. This caused
Full prefetches (which are complete but may have partial heads) to
incorrectly override `isHeadPartial` to `false`, breaking loading
boundary display for pages with dynamic metadata.

The server's `#` marker byte signals that a prerendered response is
fully static (no dynamic follow-up needed). Previously this was used to
control `ResponseCompleteness` during segment cache writes, marking
segments as non-partial. This caused two regressions:

1. Loading boundaries not showing for pages with dynamic metadata (head
   cached as non-partial when it should be partial)
2. Server action refresh breaking parallel routes (default navbar slot
   cached as non-partial, preventing dynamic data from overwriting it)

The root cause: the marker is a route-level signal but was applied as a
segment-level signal at write time.

Now, `isFullyStatic` is stored on the `FulfilledRouteCacheEntry` and
checked at read time in `createCacheNodeForSegment`. When navigating to
a fully static route with cached segment data available, the read path
overrides `isCachedRscPartial` and `isCachedHeadPartial` to skip the
dynamic request. This respects per-segment freshness: once entries
expire, the override no longer applies and a dynamic request is made.

The navigation write path (`writeStaticStageResponseIntoCache`) now
always uses `Partial` completeness. The prefetch write path still uses
`FullyStatic` for the head override since prefetch entries don't
conflict with refresh data.

The three-value `ResponseCompleteness` enum (`Partial`, `Complete`,
`FullyStatic`) was conflating two concerns: segment partiality and the
head override for fully static routes. Now that `isFullyStatic` lives on
the route cache entry, we can use it directly for the head override and
reduce the enum to a simple boolean (same as on `canary`).

- Set `route.isFullyStatic` from the prefetch write path (consistent
  with the navigation and initial HTML paths)
- Use `route.isFullyStatic` for the head partiality override in
  `writeDynamicRenderResponseIntoCache`
- Replace the enum with `isResponsePartial: boolean` in
  `writeDynamicRenderResponseIntoCache` and `writeSeedDataIntoCache`

The server prepends a completeness marker byte to RSC Flight responses.
Previously, both fully static prerenders and complete runtime prefetches
used `#` (0x23), which caused the client to incorrectly set
`route.isFullyStatic` for non-fully-static pages whose runtime render
happened to complete without aborting. This made the segment cache skip
the dynamic follow-up request at navigation time, leaving content from
non-runtime-prefetchable segments missing.

Introduce a third marker byte `*` (0x2a) for complete runtime prefetches
from `finalRuntimeServerPrerender`, reserving `#` for build-time
prerendered fully static pages. The client now only sets
`route.isFullyStatic` when it sees `#`, which is only served for pages
that are genuinely fully static.

The three markers are defined in a shared `ResponseCompletenessMarker`
enum:
- `#` (Static)   — fully static prerender, all segments present
- `*` (Complete)  — complete runtime prefetch, included segments are
                    complete but the response may omit segments
- `~` (Partial)   — partial, contains dynamic holes

Server action redirects to fully static pages include the prerendered
flight data for the redirect target, which has the
`ResponseCompletenessMarker` byte prepended at build time. The server
action reducer passed this response directly to React's
`createFromFetch` without stripping the marker, causing a `Connection
closed` error because the marker byte is not valid RSC Flight data.

Fix by running the response through `processFetch` (which calls
`stripCompletenessMarker`) before passing it to `createFromFetch`. Also
export `processFetch` so it can be reused, and preserve the `redirected`
property on the reconstructed `Response` since the `Response`
constructor does not carry it over from the original.

Delete `writeInitialSeedDataIntoCache` and `processStaticStageResponse`,
replacing their usage with `writeStaticStageResponseIntoCache` and
inline `getStaleAt` calls at each call site. This removes an async cache
write function (all cache writes should be sync, with async computations
at the call site) and eliminates duplicated logic between the initial
HTML and navigation cache write paths.

`writeDynamicRenderResponseIntoCache` and
`writeStaticStageResponseIntoCache` now take `flightData` and `buildId`
as explicit params instead of a full response object, and
`writeStaticStageResponseIntoCache` takes `headVaryParamsThenable`
instead of pre-resolved `headVaryParams`. The `responseHeaders` param is
removed — callers resolve the build ID from the deployment header before
calling.

The build ID check in `writeDynamicRenderResponseIntoCache` is changed
from `buildId !== getNavigationBuildId()` to `buildId && buildId !==
getNavigationBuildId()` so that a missing build ID (e.g. from the
initial HTML path) is treated as permissive rather than as a mismatch.

All `getStaleAt` call sites now use `.then().catch()` instead of
`.then(onFulfilled, onRejected)` so errors from both the stale time
computation and the cache write are caught.

`getStaleAt` is exported for use by external call sites.

The initial HTML of fully static pages should be cached with
`FetchStrategy.Full` and `isResponsePartial = false`, since all segments
are present and no dynamic follow-up is needed. Previously,
`writeStaticStageResponseIntoCache` was used for both navigation
responses and initial HTML, but its `FetchStrategy.PPR` +
`isResponsePartial = true` settings caused issues with mismatching
prefetch rewrites — partial entries triggered unnecessary dynamic
follow-up requests.

`writeStaticStageResponseIntoCache` is now used only for navigation
responses (static stage of PPR).

When writing fully static pages into the segment cache (via navigation
or initial HTML), segments are now written directly as non-partial
instead of using a route-level `isFullyStatic` flag to override
partiality at read time.

Default page segments are skipped during the cache write to prevent
their content from being stored at keys that collide with reused active
slots. During a refresh, the reused slot's lookup would hit these
entries and render the static default content instead of fetching fresh
dynamic data.

The filter handles two cases: segments with `__DEFAULT__` directly (the
implicit `children` parallel route), and `(slot)` virtual wrapper
segments whose `children` child is `__DEFAULT__` (named parallel route
slots like `@navbar`). The `(slot)` wrapper is a build-time construct
from `next-app-loader` that is always exactly one level deep.

`writeInitialFullyStaticResponseIntoCache` is removed in favor of
calling `writeStaticStageResponseIntoCache` with `isResponsePartial:
false`.

The head partial override in `writeDynamicRenderResponseIntoCache` is
now controlled by an explicit `overrideHeadAsNonPartial` parameter
instead of being derived from `isResponsePartial`. Only
`writeStaticStageResponseIntoCache` passes `true` for fully static
responses. This prevents per-segment prefetches and other callers from
incorrectly marking the head as non-partial, which would block dynamic
metadata from being fetched on subsequent navigations to pages with
different metadata.

A runtime prefetch can receive a statically generated response (with the
`Static` completeness marker) for a fully static page. In that case the
head is complete despite the server conservatively marking it as
partial. Without the override, navigating to a previously visited fully
static page would make an unnecessary dynamic request just for the head.

The two boolean parameters `isResponsePartial` and
`overrideHeadAsNonPartial` encoded three valid states but allowed an
invalid fourth combination. They are replaced with a single
`ResponseCompleteness` enum that distinguishes `Partial` (segments have
dynamic holes), `Complete` (all included segments are complete but some
may have been omitted based on the router state tree, or the head may
still be partial), and `Static` (the server confirmed the entire
response is fully static including the head).

Instead of the server prepending a completeness marker byte with three
possible values (Partial, Complete, Static), it now prepends a single
byte indicating whether the response is partial (contains dynamic holes)
or not, as is the case on `canary`. This simplifies the logic on both
the server and client, since the server only needs to distinguish
between partial and non-partial responses, and the client derives all
caching decisions from a single boolean. Responses without a recognized
marker (e.g. regular navigation responses that don't go through the
prerender path) are conservatively treated as partial. The head partial
override in `writeDynamicRenderResponseIntoCache` is guarded by
`process.env.__NEXT_CACHE_COMPONENTS` because the server's defensive
`isPossiblyPartialHead` marking only applies during static generation
with Cache Components enabled. Without Cache Components, the server
already sends the correct `isHeadPartial` value.

When writing a server response into the segment cache, we should not
assume that the returned tree matches the exact shape that was
requested by the client. The server sends back a patch, which must be
applied to the "base" tree (the one included in the request header) to
reconstruct the actual shape of the data. Previously, the route tree
was read from a pre-existing route cache entry, which could diverge
from the response in cases like dynamic rewrites or when handling
parallel routes. This rarely manifested as a bug, but was incorrect
in principle.

This refactors the cache write path so the route tree is always
derived from the Flight data itself, guaranteeing it stays in sync
with the response. For the static stage write path, the seed is
computed from the static stage's own Flight data, since the static
and dynamic stages may produce different trees.

This is a step in an ongoing migration from FlightRouterState to
RouteTree on the client. RouteTree is optimized for cache access
(e.g. pre-computed vary paths), but many places still expect
FlightRouterState, so both representations coexist for now. As a
next step, normalizeFlightData and convertServerPatchToFullTree
should be unified into a single pass, since they are now almost
always called together.