Description

Push-triggered runs of the Build Status workflow (pushes to main, next-*_*_*, fix-v*) no longer reuse the pnpm cache when building production packages. The setup-node step in the production_packages job now disables its cache input on push events, so dependencies are installed fresh. Pull request runs are unchanged and still benefit from the pnpm cache.

The production packages produced by push flows are the ones that may end up being published. Skipping the cache there removes any chance of a stale or partially-populated cache silently influencing the built artifacts, at the cost of one uncached pnpm install per push build — an acceptable trade-off since publishable artifacts only flow through push events.

The conditional is expressed inline as cache: ${{ github.event_name == 'push' && '' || 'pnpm' }}. setup-node treats an empty cache input as "no cache" (its if (cache) guard short-circuits), so this is equivalent to omitting the input on push runs while keeping 'pnpm' everywhere else.

Scope is intentionally narrow: only the production_packages job is affected. The other jobs (format_lint, typecheck, test, …) keep using the cache so the rest of the matrix stays fast.

Checklist

— Don't delete this checklist and make sure you do the following before opening the PR

• I have a full understanding of every line in this PR — whether the code was hand-written, AI-generated, copied from external sources or produced by any other tool
• I flagged the impact of my change (minor / patch / major) either by running pnpm run bump or by following the instructions from the changeset bot
• I kept this PR focused on a single concern and did not bundle unrelated changes
• I followed the gitmoji specification for the name of the PR, including the package scope (e.g. 🐛(vitest) Something...) when the change targets a package other than fast-check
• I added relevant tests and they would have failed without my PR (when applicable)