chore: upgrade js-yaml to ^4.3.1 to address GHSA-5p4m-2wfm-xmqj

[claude]

Fixes SOU-1883

Addresses GHSA-5p4m-2wfm-xmqj (HIGH): resolveYamlOmap() in js-yaml 3.x/4.x enforces !!omap key uniqueness with a linear indexOf scan inside the per-element loop, making resolution O(n²). Because !!omap is registered in the default schema, a plain yaml.load() on attacker-influenced YAML can block the event loop (same weakness as CVE-2026-59870, which was fixed in 5.2.1 but never backported). Fixed in js-yaml 4.3.1.

All requesters (@apidevtools/json-schema-ref-parser, @eslint/eslintrc, json-schema-to-typescript) already declare ^4.1.1 ranges that admit 4.3.1, so this is a lockfile refresh only (yarn up -R js-yaml) - no package.json or resolutions change needed.

Verification

• yarn why js-yaml --recursive reports a single instance, js-yaml@npm:4.3.1; no 4.3.0 or 3.x remains in the graph.
• yarn build:deps succeeds (regenerated schema types are unchanged).
• yarn test passes: 1846 tests across queryLanguage, shared, backend, and web.
• yarn workspace @sourcebot/web lint passes with no findings.

---

Note

Low Risk
Patch-level dependency bump with no application code changes; risk is limited to js-yaml behavior in transitive YAML parsing paths (e.g. JSON Schema ref parsing via eslint/apidevtools).

Overview
Bumps the resolved js-yaml version from 4.3.0 to 4.3.1 via a yarn.lock refresh only—no package.json or resolution changes, since transitive dependents already allow ^4.1.1.

This addresses GHSA-5p4m-2wfm-xmqj: !!omap resolution in 4.x could degrade to O(n²) and stall the Node event loop on attacker-influenced YAML passed to yaml.load(). The unreleased changelog records the upgrade under Fixed.

^{Reviewed by Cursor Bugbot for commit 1675110. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

License Audit

❌ Audit failed to produce results. Check the workflow logs for details.