Run check:compat --strict in the Release workflow (#3123)

.agents/skills/backward-compat/SKILL.md

@@ -125,7 +125,7 @@ It reports what the release has and the build lost, one key per line:
 | `js:tabler.esm.js:tabler` | a top-level export is gone |
 | `file:dist/libs/litepicker/dist/litepicker.js` | a file is gone from the package |
 
-Fix each one with the patterns from section 3, then run it again. Known breaks are listed in `.build/compat-baseline.txt`; when you fix one, delete its line, or the check fails on the stale entry. Never add a line to the baseline to make a PR green. A line gets ` # accepted: <why>` only after the maintainers decided to ship that break. CI runs the check after the build, and with `--strict` on the versions pull request, so a release cannot be merged while an unaccepted line is left.
+Fix each one with the patterns from section 3, then run it again. Known breaks are listed in `.build/compat-baseline.txt`; when you fix one, delete its line, or the check fails on the stale entry. Never add a line to the baseline to make a PR green. A line gets ` # accepted: <why>` only after the maintainers decided to ship that break. CI runs the check after the build. The Release workflow runs it with `--strict` on every push to `dev`, before it opens the versions pull request or publishes, so nothing reaches npm while an unaccepted line is left.
 
 `check:compat` compares names. `check:compat-fixture` covers behaviour: `.build/compat-fixture/` is a small project written the way a user of the last release would write it (`@use … with` on old variables, old functions, `rgba(var(--tblr-primary-rgb), .5)`, an empty `.legend`, the libraries in `dist/libs`, `tabler.tabler.getColor()`), and the check runs it against the release and against the working tree. Every assertion has to give the same answer on both.
 

.github/workflows/build.yml

@@ -23,9 +23,9 @@ jobs:
       - name: Build
         run: pnpm exec turbo build
 
-      # Nothing the last release shipped may disappear in a minor release. The
-      # versions pull request runs it with --strict, so a release cannot be
-      # merged while compat-baseline.txt still lists a break nobody accepted.
+      # Nothing the last release shipped may disappear in a minor release. On the
+      # versions pull request it runs with --strict, but workflows there wait for
+      # a manual approval, so the Release workflow runs --strict too.
       - name: Check backward compatibility
         env:
           STRICT: ${{ github.head_ref == 'changeset-release/dev' && '--strict' || '' }}

.github/workflows/release.yml

@@ -35,6 +35,15 @@ jobs:
       - name: Build
         run: pnpm run build
 
+      # The last gate before npm: nothing the previous release shipped may be
+      # missing, unless compat-baseline.txt marks it as accepted. It runs here and
+      # not only on the versions pull request, because workflows on a pull request
+      # opened by the bot wait for a manual approval and may never run. On the
+      # push that publishes, the local version is not on npm yet, so the check
+      # compares with `latest`, which is the release users update from.
+      - name: Check backward compatibility
+        run: pnpm run check:compat --strict
+
       - name: Create release Pull Request or publish to NPM
         id: changesets
         uses: changesets/action@ae32849d5ba541f9ae29e40e22a623bc13562f51 # v2.1.2