Does Dart Sass require explicit --embed-sources to include source content in source maps?

Goal: Determine whether the default source‑map behavior in Dart Sass (≥1.23) provides a reliable way to back up and verify recovered Sass source after CSS compilation.

Constraint: With the default configuration the embedSources flag is false, so generated .css.map files reference external .scss files rather than embedding their content. Verification therefore depends on the build pipeline preserving the original source files and serving them from locations that match the paths recorded in the map.

Uncertainty: If the original Sass files are moved, renamed, or omitted after compilation, the source map may point to missing or incorrect locations, breaking the ability to inspect the original Sass in browser devtools. Enabling embedSources solves this by inlining the source as base64, but it increases map size and may affect network performance.

Questions: Does relying on external source references still allow accurate verification when the original .scss files remain alongside the map? What risks arise if the build process does not guarantee the preservation or correct location of those source files? How does the trade‑off between map size and source‑availability influence the decision to enable embedSources in production debugging workflows?