rewriteRelativeImportExtensions & enforce consistent extensions

### 🔍 Search Terms

"rewriteRelativeImportExtensions", "extensions"

### ✅ Viability Checklist

- [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [x] This wouldn't change the runtime behavior of existing JavaScript code
- [x] This could be implemented without emitting different JS based on the types of the expressions
- [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [x] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

An option/param to enforce `import`s with relative paths to point to files existing in sources rather than in built files, in short, make `import`s only allowing `.ts` and not `.js` extensions when importing a Typescript file.

### 📃 Motivating Example

`rewriteRelativeImportExtensions` is a great new feature and it works well. It permits to create hybrid projects directly executed by recent nodejs versions, but also buildable by tsc for distributing them. But since we now have the possibility to use the `.ts` extensions in `import`s because they will be rewritten at compilation time, we still can continue to use the `.js` extensions in parallel, pointing to built files.
As everyone knows, nodejs requires relative `import`s to have an extension and to point to an existing file and so, extensions have to be `.ts` (or `.mts`/`.cts`) to import other Typescript files.
It would be probably great that Typescript gives us an error when using unreachable file in this context, like its quasi-exact opposite: `TS5097: An import path can only end with a .ts extension when allowImportingTsExtensions is enabled` when `.ts` extensions are not allowed by configs.

### 💻 Use Cases

1. What do you want to use this for?
In projects where nodejs can be used for any reason (tests, various scripts) and where code have to be built to be distributed over npm or any other repository, to avoid detecting bad `import`s extensions at nodejs runtime and to keep a consistent code base.

2. What shortcomings exist with current approaches?
Only its permittivity, allowing to use inconsistent `import`s styles, that may don't run in nodejs, without detecting them at coding time.

3. What workarounds are you using in the meantime?
It's not a bug, there's no need of workarounds, only vigilance.

Start by reading the existing implementation and tests for rewriteRelativeImportExtensions, then compare its behavior with allowImportingTsExtensions and diagnostic TS5097. Define how relative .js, .ts, .mts, and .cts imports should be validated, and add coverage showing that the new option rejects imports that do not resolve to source files.

Written by the indexing model from the issue text.