Reconcile browserslist target with Baseline + add CSS/JS compat linting

[mdo]

Summary

Our .browserslistrc is out of date and arguably inconsistent with the CSS features v6 already ships. We should reconcile the browser-support target — ideally moving away from hardcoded browser versions toward a Baseline-driven query — and add tooling to keep CSS/JS within that target.

This was raised by @alpadev and @XhmikosR in the review thread on #42270.

Motivation

• Hardcoded versions drift. ecmaVersion/browserslist pinned to specific versions go stale and don't express intent. @XhmikosR's point on Simplify eslint configs, modernize eslint config for docsJS #42270: rather than pinning, express support as "latest"/Baseline so it stays current.
• JS is covered, CSS is not. Babel transpiles/polyfills JS per browserslist, but on the CSS side Autoprefixer only adds vendor prefixes — it does not flag or work around unsupported features. So nothing currently guards the CSS we author against our stated support target.

Proposal

1. Replace the hardcoded browserslist with a Baseline query, e.g. baseline widely available (optionally with downstream). For reference, browsersl.ist puts our current list at ~87.5% global coverage vs ~89.3% for baseline widely available with downstream.
2. Add a CSS compat linter. @alpadev tried three and found stylelint-plugin-use-baseline the most configurable/consistent; alternatives stylelint-no-unsupported-browser-features and stylelint-browser-compat are more verbose about specific version gaps.
3. Optionally add JS-side Baseline linting via eslint-plugin-compat / the Baseline ESLint integration.

Caveat

v6 intentionally uses some CSS that is not yet "widely available" (too new for the strict Baseline tier). Any target/linter config has to account for that — likely an allowlist of known-newer features, or targeting newly available for a defined subset.

Context

Split out of the review discussion on #42270 (which was itself superseded by #42354). Filing separately so the idea isn't lost.