Cache Components: avoid retaining request context in default 'use cache' entries

## Next.js Change

**Commit:** [`c5b960e`](https://github.com/vercel/next.js/commit/c5b960e2e55ca8d20c36794bfc01cf25898ac0ba)
**PR:** [#97941](https://github.com/vercel/next.js/pull/97941)

## What changed

Next.js no longer stores live `ReadableStream` objects in its default `'use cache'` handler. A cached stream can retain the request async context and closed HTTP response that produced or consumed it, causing memory growth until eviction. The handler now buffers the stream before storage and constructs a fresh stream for every cache hit.

## Impact on vinext

Vinext must ensure its default `'use cache'` storage does not retain live streams across requests. Otherwise long-lived development, build, and Worker processes can retain completed request state for the lifetime of cache entries and eventually exhaust memory.

## Acceptance criteria

- [ ] Buffer cached `'use cache'` stream values before retaining them in the default in-memory cache.
- [ ] Return a fresh readable stream backed by the stored bytes for every cache hit.
- [ ] Preserve cached metadata, error behavior, expiry, and revalidation semantics.
- [ ] Add a regression test showing that a request context used to populate and read an entry can be garbage-collected while the cache entry remains usable.

## Related

- #1453 - Existing `"use cache"` build-time and route-handler parity work
- #2996 - Separate successful cache-prerender abort-listener retention fix
- vercel/next.js#97934 - Upstream memory-retention report

Start at vinext's default 'use cache' handler and the related build-time and route-handler parity work in #1453; trace how stream values are stored and recreated. Add the retention regression test described in the acceptance criteria, then verify metadata, errors, expiry, and revalidation remain unchanged while cached hits return fresh streams.

Written by the indexing model from the issue text.