Contain the Sass @import deprecation (test before fixing)

[Schmandarine]

Note: the obvious framing of this issue is wrong. "Migrate assets/src/scss/ to @use/@forward to pay down the Dart Sass deprecation" does not work. We import Bootstrap by relative path (@import "../../../node_modules/bootstrap/scss/...") and Bootstrap 5 uses @import throughout its own source. Changing our files changes nothing about Bootstrap's. When Dart Sass 3.0 removes @import, Bootstrap 5 breaks and our layer cannot prevent it.

Three things get conflated here. Two are this issue; the third moved to #8.

a) Noise. quietDeps classifies by how a file was loaded, and relative paths into node_modules may be treated as our own source rather than a dependency.

b) Risk. @import removal ships in Dart Sass 3.0.0, which the Sass team committed not to release before October 2026 — roughly two months out. A routine npm update should not be able to break every brmbh build overnight.

c) Structure. Modularising our own SCSS has a real justification, but it is the preset seam, not Dart Sass. See #8.

• Test first, then fix. Run the build with --quiet-deps as-is and see whether Bootstrap's warnings actually go away. The load-path theory below is unverified inference, not a known fix
• If it doesn't fire: try load-path form (--load-path=node_modules + @import "bootstrap/scss/..."). Failing that, --silence-deprecation=import is the blunt instrument that definitely works
• Whichever wins lands in tools/sass-with-theme-flags.sh
• Pin sass to <3 in the theme package.json and the create template
• Document that the real resolution arrives with Bootstrap 6 — whose development has not started, and which has shipped no release since 2025-08-26. Until then this is contained, not fixed

Agent surface

tools/sass-with-theme-flags.sh and the create template → needs a @brmbh/cli release.

---

Context: vault .../Development/Stack-Assessment-2026.md §2