[CLOV-1637] Phase 1: Drop legacy fallback declaration in bpk-themeable-property and delete duplicate dark style

[IrinaWei]

Summary

Stacked on top of #4492. Targets the bundle-size pressure surfaced by the large :root { ... } token block introduced in that PR — base.css had grown to ~15.5 KB, pushing Backpack's CSS close to the web-platform limit when consumed in apps like web-platform.

This PR applies the first two of three planned compression strategies, taking base.css from ~15.5 KB → ~ 9.77 KB.

📦 42.19.1-dev-v26385918476.1

Strategy 1: Drop legacy fallback declaration in bpk-themeable-property

packages/backpack-web/src/bpk-mixins/_utils.scss

Each callsite of bpk-themeable-property previously emitted two declarations:

// before — two declarations per use
@mixin bpk-themeable-property($property, $variableName, $fallback) {
  #{$property}: $fallback;
  #{$property}: var($variableName, $fallback);
}

The first declaration was a fallback for browsers without CSS custom property support (IE 11 and earlier). Backpack's browserslist targets are now Chrome 109+, Edge 142+, Firefox 145+, Safari 16+, Samsung 29+ — every supported browser implements CSS custom properties natively, so the bare-fallback line is dead weight.

// after — one declaration per use
@mixin bpk-themeable-property($property, $variableName, $fallback) {
  #{$property}: var($variableName, $fallback);
}

The SCSS-side \$fallback is preserved as the second argument to var(), so behaviour when the CSS custom property is undefined at runtime is unchanged. With ~167 callsites across central mixins (_buttons, _chips, _forms, _badges, _typography) and 19 component .module.scss files, halving these emissions is the highest-leverage byte-saving available without touching consumer call sites.

Strategy 2: Delta-only dark theme via a PostCSS dedupe plugin

scripts/webpack/postcss-dedupe-dark-theme.js (new), scripts/webpack/postCssPlugins.js, packages/backpack-web/src/bpk-stylesheets/webpack.config.babel.js

The token block emitted by Style Dictionary repeats every token under :root[data-theme=\"dark\"], including ones whose values are identical to the light theme. These duplicates are wasted bytes — the cascade would inherit the light value anyway.

A new PostCSS plugin (bpk-dedupe-dark-theme) is added that, when bundling theme-backpack-dark.css:

1. Reads the sibling theme-backpack-light.css and parses its :root { ... } block into a Map<propName, value>.
2. Walks the :root[data-theme=\"dark\"] rule and removes any declaration whose value matches the light theme's value for the same property.
3. Registers the light file as a webpack dependency so base.css is rebuilt when light tokens change.

Tokens that the dark theme does override remain in place; tokens that match the light value are dropped and inherited through the CSS cascade. Visual behaviour is unchanged.

The plugin is gated by filename, so it only triggers for the bundled theme-backpack-dark.css. The standalone theme-backpack-dark.css published in the package (copied without webpack) stays complete, so consumers importing the dark theme file directly still receive every token.

A small wiring change is included alongside the plugin: webpack.config.babel.js now invokes postCssPlugins() instead of passing the function reference, so the plugin list is materialised correctly.

Scope

• No callsite changes — bpk-themeable-property's signature is unchanged, all 167 existing usages continue to work.
• No browser regression at Backpack's stated support targets.
• The dark-theme dedupe applies only to the webpack-bundled base.css; standalone theme files remain complete.

What this PR does not do

• Does not remove the SCSS-side fallback values inlined as \$fallback arguments. Those continue to flow into var(name, fallback) so consumers without base.css keep rendering.
• Does not migrate components to the new token-sync variable names (the long-term fix discussed in the slack thread). That migration is separate epic-sized work.
• Does not delete the bpk-themeable-property mixin itself; that depends on the migration above.
• Does not include Strategy 3 (PostCSS class-name mangling) — that lands in a follow-up PR.