chore: add pre-push hook guarding yarn.lock drift

[Martin Hochel (Hotell)]

Problem

CI runs yarn install --immutable, but that check only ever inspects the working tree.
A lockfile that was regenerated locally and never committed therefore passes locally and
fails on CI.

That is exactly what happened in #1219: peerDependencies were edited after yarn add,
the lockfile was regenerated at some later point but the commit kept the stale copy, and
a local yarn install --immutable still reported success because it was validating the
repaired working tree rather than the commit.

The gap

Two distinct failure modes exist, and --immutable only covers one:

Failure mode	Caught by --immutable?
Manifest changed, lockfile not regenerated	yes
Lockfile regenerated, but not committed	no

Change

A .husky/pre-push hook covering both:

if ! git diff --quiet HEAD -- yarn.lock; then
  echo "pre-push: yarn.lock differs from HEAD. Commit it before pushing." >&2
  exit 1
fi

yarn install --immutable

The git check runs first because it is essentially free; --immutable is a read-only
no-op when the tree is already in sync, so the hook adds no meaningful cost to a normal push.

Note that git status --porcelain is unsuitable here: it exits 0 even when it prints
output, so it cannot gate a hook. git diff --quiet HEAD returns non-zero and covers both
staged and unstaged drift.

Verification

Scenario	Expected	Actual
Clean, in-sync tree	pass	exit 0
yarn.lock modified but uncommitted	block	exit 1, yarn.lock differs from HEAD
peerDependencies added with stale lock	block	exit 1, YN0028

This PR's own push exercised the hook.

[github-actions]

📋 PR Validation Summary

Check the Build react library job summary for detailed reports:

• 📦 Bundle Size — size comparison against the base branch

To view: click the link above → select the Build react library job → open the Summary tab.

[Copilot]

Pull request overview

Adds a Husky pre-push hook to prevent pushing when yarn.lock has drifted locally (including the “lockfile regenerated but not committed” case that yarn install --immutable alone won’t catch), aligning local checks with CI expectations.

Changes:

• Add .husky/pre-push hook that blocks pushes when yarn.lock differs from HEAD.
• Run yarn install --immutable during pre-push to catch manifest/lockfile mismatches before pushing.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Paul Mardling (PaulGMardling)]

Could an uncommitted package.json change hide a mismatch in the commit here?
For example, if I commit a dependency change without updating yarn.lock, then undo the manifest change locally without committing, both checks seem to pass while CI would still fail.
Would it be worth checking the root and workspace manifests against HEAD too?