Stale CSS after editing a Sass partial: which caching layer is actually responsible?

A project compiles Sass through a build tool (for example webpack with sass-loader, Vite, or a framework asset pipeline) on top of Dart Sass. The goal is to reliably diagnose why editing a partial pulled in via @use or @import sometimes leaves the emitted CSS unchanged until some cache is cleared.

The uncertainty is which layer caches at all. Dart Sass itself does not keep a persistent compilation cache comparable to the legacy Ruby Sass .sass-cache directory, so the staleness presumably comes from the surrounding toolchain keying on the entry file rather than the full dependency graph. Custom importers or loadPaths resolution may also mean some files never register as watched dependencies.

Assume current Dart Sass and a recent build-tool version; the legacy Ruby Sass :cache_location behavior is out of scope unless the setup turns out to be legacy.

Which specific signals distinguish a build-tool cache miss from a watcher dependency-tracking gap when a partial edit produces no output change? Does compiling the entry directly with the Dart Sass CLI conclusively rule Sass itself in or out? Is there any documented, toolchain-independent contract for cache invalidation, or must each integration be verified on its own versions?