Persist storage cache in Docker environments (#100790)
### What?
Next.js now persists its server-side storage cache in Docker
environments, the same as other environments. This covers the RSC /
Server Actions encryption key, preview-mode keys, and the development
Chrome DevTools workspace identifier.
### Why?
The shared storage-directory helper previously disabled `.next/cache`
persistence whenever Docker was detected. As a result, Docker
environments could not reuse cached RSC encryption secrets across
separate key-generation processes.
### How?
The shared helper now always resolves the cache directory beneath the
configured dist directory. Because storage is always available, each
consumer drops the now-unreachable fallback path and uses the existing
cache read/write flow directly. Existing key validation, expiry-based
rotation during builds, and `NEXT_SERVER_ACTIONS_ENCRYPTION_KEY`
precedence are unchanged.
Telemetry is intentionally unchanged: it has its own storage-location
logic for CI and Docker, which already stores telemetry configuration in
`.next/cache` there.
### Verification
- Ran a focused probe against the updated source with Docker detection
mocked. It confirmed RSC encryption-key cache write and reuse,
expired-key handling for runtime and builds, explicit encryption-key
precedence, and preview-key cache write and reuse.
- `pnpm --filter=next types`
- Not run: full Next.js integration tests.
<!-- NEXT_JS_LLM -->
<!-- fleet 3a3e1bf2-4e32-499c-8f71-ae9dd2d64f16 -->
Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>