Review: LGTM

This is a clean, well-scoped fix that faithfully mirrors the upstream Next.js change in vercel/next.js#94703.

What I verified

• Constant values match upstream exactly. NEXT_REQUEST_ID_HEADER (x-nextjs-request-id) and NEXT_HTML_REQUEST_ID_HEADER (x-nextjs-html-request-id) match the values in packages/next/src/client/components/app-router-headers.ts.
• Correct chokepoint. _getReadonlyHeaders is the single source for the headers() userland view across both routers (it's the only caller of _sealHeaders for request headers), so stripping here covers all paths. Pages and App Router both flow through it.
• Raw headers preserved. The fix copies into a fresh new Headers(ctx.headers) before deleting, so ctx.headers stays intact for internal reads — the test asserts this, matching the upstream comment that "the server reads them from the raw request headers, not from here."
• Cache invalidation is safe. applyMiddlewareRequestHeaders nulls ctx.readonlyHeaders on a middleware override (headers.ts:540), so the stripped copy is rebuilt correctly after NextResponse.next({ request: { headers } }).
• Tests pass. Ran vp test run tests/shims.test.ts -t "next/headers shim" (33 passed) and the new regression test in isolation (passes).

Note (non-blocking)

The PR title/description frame this as stripping only the dev request-id headers, but the change also now strips FLIGHT_HEADERS (rsc, next-router-state-tree, etc.) from the userland headers() view — and the test asserts that (expect(h.get("rsc")).toBeNull()). This is the correct behavior and matches upstream's getHeaders in request-store.ts, and flight headers are already stripped at the middleware boundary via requestWithoutFlightHeaders in server/app-middleware.ts, so this is sound defense-in-depth. Just worth noting the diff does slightly more than the title suggests.

No changes requested.