[Bug]: Next.js app crashes every request — auto-injected edge cache handler imports node:v8

## Summary

Every request to two Next.js apps deployed via Deno Deploy's native Next.js integration returns a bare 500 (`Internal Server Error`, no Next.js error page — a generic platform-level error), even on the root route `/`. The runtime log shows the crash happens before any application code runs:

```
Error: Failed to load external module node:v8: TypeError: Native module not found: node:v8
at u.B [as x] (.next/server/edge/chunks/0jk5_next_dist_esm_build_templates_edge-wrapper_0t.~ot_.js:1:8334)
at (.next/server/edge/chunks/[root-of-the-server]__0r-jri-._.js:9:104244)
at i.a (.next/server/edge/chunks/0jk5_next_dist_esm_build_templates_edge-wrapper_0t.~ot_.js:1:3965)
at module evaluation (.next/server/edge/chunks/[root-of-the-server]__0r-jri-._.js:9:104217)
at L (.next/server/edge/chunks/0jk5_next_dist_esm_build_templates_edge-wrapper_0t.~ot_.js:1:7436)
at K (.next/server/edge/chunks/0jk5_next_dist_esm_build_templates_edge-wrapper_0t.~ot_.js:1:6977)
at u.g [as i] (.next/server/edge/chunks/0jk5_next_dist_esm_build_templates_edge-wrapper_0t.~ot_.js:1:2513)
at (.next/server/edge/chunks/[root-of-the-server]__0r-jri-._.js:52:11641)
at i.a (.next/server/edge/chunks/0jk5_next_dist_esm_build_templates_edge-wrapper_0t.~ot_.js:1:3965)
at module evaluation (.next/server/edge/chunks/[root-of-the-server]__0r-jri-._.js:52:11565)
```

`node:v8` is a Node-only built-in (used for `serialize`/`deserialize`); the Edge Runtime doesn't support it. This project's own code never imports `node:v8` anywhere. The build itself also warns about this during `deno task build`:

```
Turbopack build encountered 1 warnings:
./apps/admin/.deploy/caches/incremental.js:104:1
A Node.js module is loaded ('node:v8' at line 104) which is not supported in the Edge Runtime.
102 |
103 | // cache_handler.ts
> 104 | import { deserialize, serialize } from "node:v8";
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
105 | var cacheName = "deno-nextjs-incremental";
106 | var cache = await caches.open(cacheName);
107 | var CACHE_HANDLER = {
```

`.deploy/caches/incremental.js` (the `deno-nextjs-incremental` cache handler) is auto-injected by Deno Deploy's own Next.js integration — it isn't part of the app's source. It appears to get bundled into the Edge Runtime chunk (which the app's `middleware.ts` uses, via `clerkMiddleware`), where `node:v8` can't load, crashing every request that touches middleware — which given the middleware matcher, is effectively every request.

## Reproduction

- Next.js 16.2.3, Turbopack
- App Directory-scoped monorepo project ("Native Next.js integration" framework preset), `deno install` / `deno task build`
- `middleware.ts` at the app root using `clerkMiddleware` from `@clerk/nextjs/server`, matcher covering most routes (standard Clerk App Router setup, nothing unusual)
- Build succeeds (only the warning above); every runtime request 500s identically, both on the Production timeline and Preview deployments

## What we've tried

- Setting `output: "standalone"` in `next.config.ts` (Deno's own docs recommend this for Next.js on Deno Deploy) — build still succeeds, but the runtime crash is identical (same error, same stack shape).

## Environment

- Two separate projects hit this identically (both use `clerkMiddleware`)
- Related, possibly relevant: #830 (a separate open Next.js-on-Deno-Deploy issue, different root symptom — worth checking if these share a cause in the Next.js integration's build/bundling step)

## Ask

Is `cache_handler.ts`'s `node:v8` import supposed to be scoped out of Edge Runtime bundles? Is there a way to disable the auto-injected incremental cache handler for apps that don't rely on ISR, as a workaround until this is fixed?

Start with the auto-injected .deploy/caches/incremental.js and the build output from deno task build, then inspect how middleware.ts brings that handler into the Edge Runtime. Compare the behavior with next.config.ts output: "standalone" and related issue #830. Done means requests no longer crash because node:v8 is bundled into the Edge Runtime, or a confirmed workaround disables the handler.

Written by the indexing model from the issue text.