This is a really great point. I think something like a `.svelte.js` file extension is warranted here. This would key tooling to when it needs to interpret runes, and makes it clear which files in a codebase require the svelte compiler. These files clearly aren't just js/ts at this point, but I think its fine as long as they're marked as such. Custom react hooks, for instance, aren't usable outside of the runtime but can be transpiled without issues by esbuild/tsc and interpreted correctly by a js/ts language server.
As long as it's marked separately from js/ts I don't think its a huge issue though. Svelte files already have script tags that aren't completely vanilla js/ts.
Ironically typescript doesn't have a supported language server from MS. TSServer (in the typescript npm package) is language server-esque and that's what VS Code plugs into. I believe the main language server for typescript is maintained by sourcegraph.
VS Code is written in typescript though and the projects have a pretty nice cadence of new features. Typescript is very much a first class citizen in VS Code
Pretty much anything that comes from Microsoft today that is a web app, or uses the HTML for UI on the desktop (such as Electron apps), is likely to be written in TS. Not even because there's some push to do so, but because people who mostly write in C# and C++ find TS far more preferable.
(That, by the way, is one reason why you can trust that it's not going away anytime soon.)
As long as it's marked separately from js/ts I don't think its a huge issue though. Svelte files already have script tags that aren't completely vanilla js/ts.