Giving an error type to types that have failed to resolve, instead of any

Nobody has claimed this yet.

### 🔍 Search Terms

Types that fail to import should not be typed as any. SkipLibCheck. Type resolution failure.

### ✅ 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

Currently if TS fails to resolve a type, for example because it can't resolve an import, the type is set as `any`. TS will display the type by it's alias (the local name given to the type), hiding that fact that it is `any` underneath. `any` being a special type that largely disables type checking, being silently introduced, can hide code errors.

Failing imports are typically reported by TS as an error, even if using that `any` typed type later on doesn't produce an error. However if there is a type resolution failure within an external module with skipLibCheck turned on (which is widely used and recommended, for multiple reasons), then there is no error and an `any` type is silently introduced to the project types.

The suggested solution is instead type these types with an error type, working name: `failed`. An assignment to or from a `failed` type is an error, like an opposite to `any`.

--

I've ticked non-breaking, even though it could lead to compilation of existing code failing, because it would only be highlighting an error that previously wasn't highlighted. It's non-breaking in valid code.

There would be a degree of annoyance never-the-less in triggering compilation errors in code that previously compiled, caused by problems in external libraries. Error messages indicating where the type resolution failed would be very helpful here.

I'm putting this out for discussion, because it's difficult for me to foresee the full consequences and challenges of such a change.

### 📃 Motivating Example

In this simple [Playground](https://www.typescriptlang.org/play/?target=11&jsx=0#code/LAKA9GAEDGD2B2AXApkysBmkCW8AmyAHgHQBWAzpBgE6wC2kAtI7itfAIYA2j1y5sLgFdE2BI2TVa1AFyhQEHHQAOsaokgBvSAGFIAXyq0GAcmJhoxRORMKoRVesiIAnsuSQAGpAC8Wu5CBgRwykPBCdABGkgA0AUGQkaHkiNS4AOZx4FAJ0KE6Afry2ZDmltaQeLD8YbAaRNgpMZACujiUyBgYyNCiAG7IXC6QHPAuxdgqahqu7lpeBkb0kCbMrJKcPHwCwqLiktK2IKCzHgD6vl4A2ibQJgC68QkJAHoA-AEAKgDK7TDcXAyzgAFo1EsNsIgTJRuNgOJQTDoTM1IiI2mDRiNAZRMCtRi5kZBQXggYhgRwNBgOL1inB4ClIIRQt4-JpQAkQpAAIxZBJJFYYWCwZHsoJ5SAAJlARRAkFAJGgAXetIQDJcyVSQL8CsgiiFynIzQA7h54eRsOl4Mg8CMwhFotRnLBbSk0vB0pA+hw0hxIlwPEbIcDYGiDmpyMUgA) we import a type from a package with an internal resolution error, that leads a type X['c'] to be `any`. TS reports no errors to us and lets us perform type-irrational operations.

### 💻 Use Cases

Fairly obviously, it's a safeguard against mistakes in external libraries, and it would also make broken imports more obvious by showing errors at the use site not just at the import site.

This occurred to me when dealing with a typing issue in `@stripe/stripe-js` (1.3M weekly downloads) [stripe-js#714](https://github.com/stripe/stripe-js/issues/714#issuecomment-2616237463). Just fixing the import in the index file as the maintainer suggested would have introduced this issue to that library.

Start with the linked Playground example and the suggestion's discussion of failed imports, external modules, and skipLibCheck. Investigate how unresolved types currently become any and determine the intended behavior and diagnostics for a proposed failed type. Done would require an agreed design that handles the motivating example without silently weakening type checking.

Written by the indexing model from the issue text.