Extra incorrect export in index.d.mts

Possible bug

When running in typescript, there's an export const sharp: SharpConstructor which doesn't actually exist in the JS. This export allows import { sharp } from 'sharp', but there is no const sharp exported from the JS so an error is produced on runtime.

import { sharp } from 'sharp';
         ^^^^^
SyntaxError: The requested module 'sharp' does not provide an export named 'sharp'
    at ModuleJob._instantiate (node:internal/modules/esm/module_job:226:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:335:5)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:665:26)
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:117:5)

Is this a possible bug in a feature of sharp, unrelated to installation?

• Running npm install sharp completes without error.
• Running node -e "import 'sharp'" completes without error.

If you cannot confirm both of these, please open an installation issue instead.

Are you using the latest version of sharp?

• I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.

If you cannot confirm this, please upgrade to the latest version and try again before opening an issue.

If you are using another package which depends on a version of sharp that is not the latest, please open an issue against that package instead.

What is the output of running npx envinfo --binaries --system --npmPackages=sharp --npmGlobalPackages=sharp?

System:
OS: Windows 11 10.0.26200
CPU: (16) x64 Intel(R) Core(TM) Ultra 9 285H
Memory: 18.64 GB / 31.59 GB
Binaries:
Node: 22.22.1 - C:\nvm4w\nodejs\node.EXE
npm: 11.19.1 - C:\Users\JasonTremper\AppData\Roaming\npm\npm.CMD
npmPackages:
sharp: ~0.35.4 => 0.35.4

Does this problem relate to file caching?

The default behaviour of libvips is to cache input files, which can lead to EBUSY or EPERM errors on Windows.
Use sharp.cache(false) to switch this feature off.

• Adding sharp.cache(false) does not fix this problem.

Does this problem relate to images appearing to have been rotated by 90 degrees?

Images that contain EXIF Orientation metadata are not auto-oriented. By default, EXIF metadata is removed.

• To auto-orient pixel values use the parameter-less rotate() operation.

• To retain EXIF Orientation use keepExif().

• Using rotate() or keepExif() does not fix this problem.

What are the steps to reproduce?

Attempt to run the following typescript

import { sharp } from 'sharp';

console.log("hi");

What is the expected behaviour?

EXPECTED: This should fail in tsc since there is no exported const in the JS
ACTUAL: This transpiles fine when run through tsc due to the extra export & failes during runtime

Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem

See above

Please provide sample image(s) that help explain this problem

n/a

Start in scripts/build.mjs around line 111 and inspect how index.d.mts is generated. Compare the declaration's exports with the runtime JavaScript exports, then reproduce the TypeScript example to confirm that importing the nonexistent named export fails during type checking rather than only at runtime. Done means the declaration no longer permits import { sharp } from 'sharp' while valid exports remain usable.