Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.1.0: Sun Oct  9 20:15:09 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.8.0
      npm: 9.4.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 13.3.0
      eslint-config-next: 13.3.1
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

Middleware / Edge (API routes, runtime)

Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/floral-cache-o8jqgq

To Reproduce

# /pages/api/example_head_response.tsx:

import { NextResponse } from "next/server";
import type { NextFetchEvent, NextRequest } from "next/server";

export const config = {
  runtime: "edge",
};

export default async function handler(
  req: NextRequest,
  context: NextFetchEvent
): Promise<NextResponse> {
  console.log("running!");
  return new NextResponse(null, {
    status: 200,
    headers: [
      ["Content-Length", "4242"],
      ["Content-Type", "audio/mpeg"]
    ],
  });
}

Describe the Bug

The 'Content-Length' header is explicitly stripped from the response, by this next/sandbox code snippet:
https://github.com/vercel/next.js/blob/canary/packages/next/src/server/web/sandbox/sandbox.ts#L108-L110

Usually, automatic setting of content-length is desirable (to automatically match the byte-size of the body field). However there are occasions when Content-Length should NOT match the body's content length in bytes.
One prominent example is in responses to HEAD requests, where only the headers should be returned, without a body.

This is commonplace when dealing with remote media files, e.g. MP3 files served over a URL -
where the initial response always includes the full file size in the Content-Length, with an empty body.
(Clients use this information to present the relevant UX, as well as to orchestrate subsequent requests to the remote server).

Expected Behavior

Headers explicitly set programmatically should be kept in place.

At the very least, there should be a mode that enforces this.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

Vercel