updating dependencies

[celiac747]

updating dependencies to remove security vulnerabilities

[celiac747]

the churn is entirely explained by two compounding factors:

1. @swc/plugin-relay: ^7.0.0 → ^12.0.0 — this is the main driver

A 5-major-version jump triggered a cascade:

@swc/core bumped from 1.11.20 → 1.15.18 (plugin-relay v12 requires a newer core)
@swc/plugin-relay v12 added a new transitive dependency on esbuild@0.27.x
Each of @swc/core and esbuild ships ~11 platform-specific optional packages (core-darwin-arm64, core-linux-x64-gnu, esbuild-win32-x64, etc.)
So that one bump alone accounts for: ~11 @swc/core platforms × 2 (remove+add) + ~15 esbuild 0.27.x new entries = ~37 package entries, each with 3–4 lines.

2. Esbuild patch-level bumps — in main the lock already had two esbuild versions (0.17.17 from scripts, 0.25.1 from storybook/vite). Both got patched:

0.17.17 → 0.17.19
0.25.1 → 0.25.12
0.27.4 added (from @swc/plugin-relay v12)
That's 3 esbuild versions × ~15 platform packages = ~45 entries coming and going.

In summary:

Change Lock file lines changed (approx)
@swc/core 1.11→1.15 (11 platform pkgs) ~90
esbuild 0.17.17→.19, 0.25.1→.12, new 0.27.4 (15 platforms × 3) ~360
Other @swc/plugin-relay transitive deps ~100
New minimatch resolutions (affects a few nested entries) ~50
The resolutions for minimatch contributed very little. It was the @swc/plugin-relay major bump that made the diff look like a full regeneration. The lock file itself was not deleted and recreated — yarn install just naturally churned many entries due to the platform-specific optional packages multiplying every version change.