@next/mdx: Turbopack rule uses `as: '*.tsx'` causing unnecessary double-processing of MDX output

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/staging-monad-ns775c

To Reproduce

1. Create a Next.js app with @next/mdx and Turbopack enabled (default in canary).
2. Add a page like app/heavy/page.mdx that uses rehype-katex with several math equations.
3. Run next dev.
4. Observe that compilation of the MDX file takes significantly longer than expected.

The slow path is triggered by as: '*.tsx' in the Turbopack rule inside packages/next-mdx/index.js, which routes already-compiled JavaScript through Turbopack's TypeScript/JSX pipeline a second time.

Current vs. Expected behavior

Current: The Turbopack loader rule for .mdx files sets as: '*.tsx', which tells Turbopack to re-process the loader output through its full TypeScript/JSX pipeline (type-stripping → JSX transform → source-map merge). @mdx-js/mdx already compiles MDX to plain JavaScript using the automatic JSX runtime (_jsx()/_jsxs() calls). The output contains no JSX syntax and no TypeScript, so the extra pipeline is pure overhead. For large outputs (e.g. rehype-katex on a math-heavy page: ~1.9 MB), the redundant source-map merging alone adds ~50 s of compilation time.

Expected: The rule should use as: '*.js' so Turbopack treats the loader output as plain JavaScript and skips the unnecessary TypeScript/JSX pipeline. The fix is a one-line change:

- as: '*.tsx',
+ as: '*.js',

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.12.1
  npm: 10.5.0
  Yarn: 1.22.19
  pnpm: 8.15.6
Relevant Packages:
  next: 16.2.0-canary.85 // Latest available version is detected (16.2.0-canary.85).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 5.9.3

Which area(s) are affected? (Select all that apply)

Markdown (MDX)

Wh