App Router dev still fails on raw CommonJS packages from node_modules

## Background

PR #665 fixes Pages Router dev for raw CommonJS packages from `node_modules` by making the direct dev module runner CommonJS-aware. App Router still fails in a separate pipeline.

## Reproduction

1. Create an App Router project with `app/page.tsx`:

```tsx
import dep from "cjs-node-package";

export default function Page() {
return

;
}
```

2. Add a CommonJS-only package in `node_modules/cjs-node-package/index.js`:

```js
module.exports = { value: "from-cjs-package" };
```

3. Run `vinext dev` and request `/`.

## Current result

Dev returns `500` and the response includes a Vite/RSC parse error:

```txt
A module cannot have multiple default exports
```

In my repro, that surfaced from the generated/prebundled `@vitejs_plugin-rsc_vendor_react-server-dom_server__edge.js` path rather than from the package source directly.

## Why the Pages Router fix does not apply

- Pages Router uses `createDirectRunner()` in `packages/vinext/src/server/dev-module-runner.ts`.
- App Router does not use that runner for request-time module loading.
- App Router goes through `@vitejs/plugin-rsc` plus vinext's `rsc`/`ssr` environments configured in `packages/vinext/src/index.ts`.
- Those environments currently force `noExternal: true` (except for explicit externals), so raw `node_modules` packages are still pushed through Vite/plugin-rsc transforms.

## What a fix likely needs

- Add a focused App Router regression test for a raw CommonJS package from `node_modules`.
- Decide whether these packages should be externalized from the App Router `rsc`/`ssr` environments in dev, or transformed into valid ESM/CommonJS-compatible modules before `@vitejs/plugin-rsc` sees them.
- Keep the existing reasons for `noExternal: true` in mind: CSS/assets in `node_modules`, RSC bundling, and React Server condition handling.
- Verify parity against Next.js App Router for CommonJS-only dependencies.

## Constraints / notes

- This is a different problem from #585 after PR #665 lands.
- A direct-runner evaluator fallback is probably not enough here because the failing path is inside the App Router RSC pipeline, not the Pages Router direct-runner path.