Generic TypedArray constructors have only one overload

### 🔎 Search Terms

Uint8Array

### 🕗 Version & Regression Information

- This is the behavior in versions 5.8.3 and 5.7.3
- I was unable to test this on prior versions because `Uint8Array` is not generic in earlier versions

### ⏯ Playground Link

https://www.typescriptlang.org/play/?target=11&ts=5.8.3#code/MYewdgzgLgBBIFcBOwCmMC8MyoO4wFUBLMKADgEEkkBDATwAoBGABgEoBuAKC9EllAAHOk0zY8hEuSq1G8ZGk69w0GELoAmMTnzFSlavQA8M+gCEEAM0uokAGSIBrVAD4G8lKiV9V6gMzaEnrShnQmoRbWtm4eitxAA

### 💻 Code

```ts
const source = new Uint8Array(10);

const copy1 = new Uint8Array(source); // OK
const copy2 = new Uint8Array(source); // TS 2345
const copy3 = new Uint8Array(source); // TS 2345
```

### 🙁 Actual behavior

Only the generic constructor overload of `Uint8Array` is available when using `Uint8Array` with a generic parameter, i.e. the one which accepts a `TArrayBuffer` as the first argument. It is therefore not possible to pass a `Uint8Array` as the first argument without a compile error, even though this is valid.

### 🙂 Expected behavior

It should be possible to use all the valid overloads of `Uint8Array` (and friends) constructor without a compiler error.

### Additional information about the issue

This seems to only affect `target` value of `ES2024` or `ESNext`, but I can't figure out why from looking at the types.

I assume this behaviour occurs for the same reason as given in [this comment](https://github.com/microsoft/TypeScript/issues/60745#issuecomment-2538876758). In that case I assume the fix would be adding copies of all the constructor overloads to the `Uint8ArrayConstructor` interface, but with type parameters.

For example, the following works ([TS Playground](https://www.typescriptlang.org/play/?target=11&ts=5.8.3#code/JYOwLgpgTgZghgYwgAgKqjADgIJSnATwGEB7EAZzCgFcEwSpkBvAKGXeQHpPkwALYOWSDkAK2qVkcZAhIAHAshIxkEAB6CwoAOZKAbtAA2JOABNyAGmQB3YP2QADACq58BAELUYMaA+Ry4fABbKVNTCFM2DhAIa2QAHhc8Qk9vaFU1SBBzZFcUrx8oABlgAGsUAF5c5I8C6AA+AAoojmRDCBBtfgAuZBBqIIAjaAsW5ABKXvRwHBrEvNq0qHqAbjGYuPma1MKMrJyFnegS8uQqw7rl5tb2QLdehZOIeP6hhtHWybQMWbcttyOyzWrQ2CSSAMuew6B22lyeZ2qEKWTTG7EGlwesKWHxugwIkAA8t5yBAwAB+XqvYZQHGtdqdfgUvoDam0iZTH4Lf75ZHA6KxMEXJZQ7JCIWFeHnLGFFE3KQ1TFuJ4vFkNZAAH0RPMKbK+0ywXPB2oaawAviwWLIKGBkOQSNQoEgEaD9b9CI0AIwABnGa0tZEksgUHudAtdC0adodSF9-utMnkBAATKG4uG5uLjmUIE0o46ILGrYHEwBmVPfGZczNXPMxtZAA)):

```ts
interface Uint8ArrayConstructor {
// this is just a copy of existing overloads, with `TArrayBuffer` param added
new (
length: number,
): Uint8Array;
new (
array: ArrayLike,
): Uint8Array;
new (
buffer: ArrayBuffer,
byteOffset?: number,
length?: number,
): Uint8Array;
new (
array: ArrayLike | ArrayBuffer,
): Uint8Array;
}

const source = new Uint8Array(10);

const copy1 = new Uint8Array(source);
const copy2 = new Uint8Array(source);
const copy3 = new Uint8Array(source);
```

I think this is basically the opposite problem to that which was fixed by #60934.

Start with the linked TypeScript Playground and compare the Uint8Array constructor behavior under ES2024 and ESNext. Review the generic Uint8Array constructor declarations described in the issue, then verify that the length, array-like, and buffer overload examples compile with explicit type arguments.

Written by the indexing model from the issue text.