fix: resolve revalidate from cacheControl for null (notFound) page values

[aevarOrigo]

Summary

resolveRevalidateValue() only reads ctx.cacheControl.revalidate when the cached value's kind is "APP_PAGE" or "PAGES". But when a Pages Router getStaticProps/getServerSideProps returns notFound: true, there's no page content to cache, so Next.js's response cache calls CacheHandler#set() with incrementalCacheValue set to null — it has no kind at all.

That means the else if never matches for notFound: true responses, revalidate falls through to ctx.revalidate, which the pages-router response cache never actually populates (response-cache/index.js only ever passes { cacheControl, isRoutePPREnabled, isFallback } into incrementalCache.set()), and the entry silently gets defaultStaleAge instead of the revalidate value the page actually returned alongside notFound: true.

Repro

// pages/[stationId].tsx
export const getStaticProps = async (context) => {
  if (invalid) {
    return { notFound: true, revalidate: 10 };
  }
  // ...
  return { props: {...}, revalidate: 30 };
};

• Success path: cached value has kind: "PAGES" → ctx.cacheControl.revalidate (30) is read correctly.
• notFound: true path: cached value is null → falls through to ctx.revalidate (undefined) → defaultStaleAge is used instead of 10, regardless of what the page returned.

With the default defaultStaleAge of 31536000 (1 year), every notFound: true response ends up with a ~1 year stale age in the underlying store no matter what revalidate the page specifies.

Fix

Also read ctx.cacheControl.revalidate when the incremental cache value is null/undefined, since that's exactly where the intended revalidate time already lives for notFound: true responses.

Test plan

• Added resolveRevalidateValue.test.ts covering FETCH, APP_PAGE, PAGES, null (the fix), undefined, unknown kind, and the no-value/no-ctx fallback cases.
• pnpm test in packages/nextjs-cache-handler — all 34 tests pass.
• pnpm build (tsup --dts-resolve) — builds cleanly, no type errors.

Happy to adjust the approach if you'd prefer handling this differently (e.g. inside CacheHandler#set() instead of resolveRevalidateValue()).

[AyronK]

This PR conflicts with #232.

[AyronK]

I don't agree that cachedPageValue == null is the right call here, it's not even === comparison.

If anything I'd go with return revalidate ?? responseCacheCtx.cacheControl?.revalidate ?? ctx.revalidate;