Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.98.2
• OS Version: Windows 11 24h2

Steps to Reproduce:

1. Set your editor to use the theme-seti icon theme
2. Create a language extension for a new file type, "SSS," that includes the following code in package.json:

{
	"name": "sss",
	"version": "0.0.1",
	"categories": [ "Programming Languages" ],
...
	"contributes": {
		"languages": [
			{
				"id": "sss",
				"extensions": [".sss"],
				...
				"icon": {
					"light": "images/icon-sss.png",
					"dark": "images/icon-sss.png"
				}
			},
...

2. Create any suitable or test image for "icon-sss.png"
3. Test the extension in an Extension Development Host window.
4. Create a new text file and manually assign it to your new language using the "Select Language Mode" option. Note that your new icon is being used.
5. Save your new file as "filename.sss"
6. Note that the filetype icon is now set to the CSS "#" icon as defined in theme-seti, because of (I believe) these lines of code in vscode/extensions/theme-seti/icons/vs-seti-icon-theme.json: 1, 2

Presumably, "SSS" is not the only example where this is true, but it took me awhile to figure out as I had no other language installed that claims the ".sss" extension, and indeed that extension is not really used anymore for CSS (or SASS) files, as far as I know.

This example just illustrates the issue, though. The upshot seems to be that an icon theme will give priority to the file extension in the filename, and not respect the selected language in that case, which seems backwards to me.

Icon themes should have priority over language extensions in most cases, but not in this way I don't think. It seems like unexpected behavior.

I can anticipate issues with a solution that uses the language, since icon themes usually have many more icons than they expect users to have installed languages, but perhaps there can be priority logic. If a language that claims that extension is not installed or is otherwise unknown to the editor, then it can go ahead and assign the icon on the file extension alone. That said, I'm surely not accounting for all cases.

I suppose this might(??) require an API change to icon themes, where each item would need to list the languageId as well as the file extension, but in that case the previous behavior could remain for icon themes which are not updated. It's mainly theme-seti that I'm worried about, since that's the one most people use.