`backdrop-filter` is dropped when it precedes a hand-written `-webkit-backdrop-filter`

When a rule declares the standard backdrop-filter first and the -webkit- prefixed form second, Lightning CSS keeps only the prefixed declaration. The standard property is gone from the output, so Firefox (which never honoured the -webkit- alias) renders no blur.

Reproduction on lightningcss 1.33.0 (also seen on 1.32.0):

import { transform, browserslistToTargets } from 'lightningcss';
import browserslist from 'browserslist';

const css = '.g{backdrop-filter:blur(20px);-webkit-backdrop-filter:blur(20px)}';
const targets = browserslistToTargets(browserslist('firefox >= 100'));
console.log(transform({ filename: 'x.css', code: Buffer.from(css), targets }).code.toString());

Output:

.g {
  -webkit-backdrop-filter: blur(20px);
}

Expected: the standard backdrop-filter survives (and the prefix is added or removed according to targets). With the declarations in the other order (-webkit- first) the output is backdrop-filter: blur(20px) only, which is correct for that target.

Why it bites: the standard-then-prefixed order is what most snippets and older autoprefixer output use. The failure is silent, pnpm dev (no Lightning CSS) shows the blur, the production build does not. A @supports not (backdrop-filter: ...) fallback does not fire either, because those browsers do support the standard property.

Looks like the two are treated as one logical property and the last declaration wins. #403 is related but is about the prefixed form being emitted twice; this one loses the standard form entirely.

Environment: lightningcss 1.33.0 via the Tailwind 4 Vite plugin, Node 24, Windows 10.