Add prek check comparing pnpm.overrides against UI workspace lockfiles and Fixes a pre-existing overrides drift in fab's lockfile that the new check caught.

[RehanAhmad25]

Picks up the third item from the follow-up checklist on #72298 : a prek check that compares each UI workspace's pnpm.overrides (package.json) against the overrides: block pnpm mirrors into that workspace's pnpm-lock.yaml, and fails with a clear message naming the exact keys that drifted, instead of surfacing as ERR_PNPM_LOCKFILE_CONFIG_MISMATCH deep in a hook log.

This does not fix the underlying issue. It doesn't identify why dependabot drops the block on some updates (checklist item 1) and doesn't implement a durable fix (item 2). A grouped dependabot PR that hits the bug will still fail static checks and still need a human to regenerate the lockfile , this only makes that failure legible instead of cryptic. Leaving 1 and 2 open for separate discussion.

While testing this against main, the check caught a pre-existing drift: providers/fab/.../www/pnpm-lock.yaml carries a moment-timezone override that was missing from package.json's pnpm.overrides (leftover from an old
yarn resolutions setup, before this workspace moved to pnpm). Fixed that in this PR since the new check would otherwise fail on main immediately.

related: #72298

---

Was generative AI tooling used to co-author this PR?

• Yes (Claude)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[kaxil]

Closing this. The "drift" it reports in the FAB provider isn't drift: package.json carries moment-timezone under resolutions, and pnpm-lock.yaml already lists it in its overrides: block. The check only reads pnpm.overrides, so it flags a consistent pair. The underlying problem in #72298 was fixed by #72390, which pinned the pnpm version, and the issue is closed.