fix(deps): patch HIGH-severity fast-uri and js-yaml CVEs

[ajayrgb]

Summary

• Trivy flagged 6 HIGH vulnerabilities in yarn.lock: fast-uri SSRF/host-confusion (CVE-2026-75899, CVE-2026-75931, CVE-2026-75975, CVE-2026-76172) and js-yaml DoS (CVE-2026-84375)
• Bumped resolutions in package.json to pull in patched versions (fast-uri -> 3.1.7, js-yaml -> 3.15.2/4.3.2) and regenerated yarn.lock
• Pinned packageManager: yarn@3.6.4 so yarn install always uses the Berry-compatible version that matches this repo's lockfile format, instead of whatever classic/Berry yarn happens to be on PATH

Test plan

• trivy fs --scanners vuln shows 0 vulnerabilities (was 6 HIGH)
• yarn install completes cleanly with pinned yarn 3.6.4
• tsc --noEmit passes with no new type errors

🤖 Generated with Claude Code

[pjdoland]

Hi Ajay,

Thanks so much for putting this together. Getting the fast-uri and js-yaml advisories patched is really valuable, and the details all check out: the five CVEs are real HIGH advisories, the versions you picked are the first patched releases, and the resolutions are scoped nicely so the js-yaml 3.x and 4.x consumers each stay on their own major.

I wanted to flag the CI failures, since I think they come from a small tooling mismatch rather than anything in the bump itself, and I'd love to help get this merged.

What seems to be happening. The lockfile looks like it was regenerated with Yarn 3.6.4, but this repo builds with jlpm, which bundles Yarn 3.5.0. Those two versions compute a different hash for Yarn's built-in TypeScript compatibility patch, so regenerating picked up an unrelated change to that entry (hash=85af82 became hash=b5f058). CI runs an immutable install with 3.5.0, sees the lockfile would change, and stops with YN0028, which is what fails both build and check_release. I was able to reproduce it in both directions locally: jlpm fails on this branch with exactly CI's error, and Yarn 3.6.4 fails the same way on an untouched main.

A possible fix. Would you be open to removing the packageManager line and re-running jlpm install? When I tried that locally, the lockfile ended up differing from main only in the three intended packages (fast-uri 3.1.7, js-yaml 3.15.2, and js-yaml 4.3.2), and jlpm install --immutable passed. CONTRIBUTING.md touches on this too: unexpected lockfile changes usually mean the local Yarn differs from the one bundled with JupyterLab, and it recommends using jlpm directly.

The reason I'd suggest dropping the pin rather than updating it: jlpm runs its bundled Yarn and ignores that field, so it never affects CI or the build, but it does cause CI to run corepack enable, and anyone who types yarn install would get 3.6.4 and land back on this same lockfile change.

Please let me know if I've misread anything. I'm also very happy to push the change or pair on it if that would save you some time.

Thanks again for picking this up!

[ajayrgb]

Confirmed your diagnosis — reproduced the hash mismatch locally (jlpm/3.5.0 vs the pinned 3.6.4) and applied your suggested fix: dropped the packageManager line, regenerated with jlpm install. The lockfile diff is now limited to the typescript builtin-patch hash reverting back to what 3.5.0 produces (85af82), package.json loses the pin line, and jlpm install --immutable passes clean. Pushed in 608b219. Thanks for the thorough writeup and repro steps — saved a lot of time.

[pjdoland]

LGTM.