What you're asking for simply isn't possible (at least in the general case) because of two reasons:
1. A CSS stylesheet cannot be interpreted without a corresponding document (HTML, usually) with which to test CSS selector rules against.
2. Excepting static sites, HTML is generated dynamically, which means (thanks to our old friend, The Halting Problem) impossible (in the general case) for tooling to use static-analysis-based approaches for CSS linting when given even a basic document-outline or structure for, for example, a React/JSX application.
(CSS static-analysis also got 100x harder when the `:has()` selector was introduced, because it invalidates a number of optimizations possible due to CSS's original (and strict) "forward-only" design (i.e. before `:has()`, CSS selectors could only match elements based on their ancestors or previous-siblings: never their descendants or next-siblings, which also meant that selectors didn't need to be re-evaluated as the document's HTML was still being loaded)
-----
Existing tooling does what-it-can, for example, I've been often surprised at how well Visual Studio (not VS Code)'s HTML/Razor editor can make very reasonable CSS class suggestions when typing-out HTML - and while there's often good stuff in the Node/npm ecosystem, especially for typical frontend dev scenarios, like building SASS/LESS in a Grunt build), a common problem I've run into is the tooling breaking completely whenever I want to use an ultramodern CSS feature, especially those that introduce a new syntax - YMMV, of course.