Hugo extended vs standard binary: which edition should CI standardize on for Sass and WebP?

Our Hugo site is growing, and we keep hitting the same fork in the road: some features only work with the extended binary. SCSS compilation through Hugo Pipes (resources.ToCSS) requires the embedded Sass transpiler that ships only in the extended edition, and WebP encoding in the image pipeline is documented as extended-only as well (standard builds can decode WebP but not produce it).

The awkward part is that this is a hard build dependency, not a graceful degradation: a template calling a Sass- or WebP-dependent function under the standard binary fails the build outright. Meanwhile, our install sources differ — some developers get Hugo via a package manager, CI uses a Docker image, and deploy previews use yet another channel — and these channels do not all default to the same edition. We can detect the edition with hugo version output or hugo.IsExtended in templates, but detection is not a policy.

We want one consistent rule across local development, CI, and preview builds, without pinning to an edition that silently limits which themes or features we can adopt later.

Is there a documented downside (size, licensing, platform availability) to simply standardizing every environment on the extended binary? If we instead pin the standard binary, what is the most reliable way to make Sass/WebP usage fail early and loudly in CI rather than at deploy time? Does the edition requirement vary meaningfully across recent Hugo versions in a way we should encode in our version pinning?