fix(deps): floor js-yaml on 4.3.1 — GHSA-5p4m-2wfm-xmqj (high)

[sweetrb]

GHSA-5p4m-2wfm-xmqj (high) — quadratic CPU consumption resolving !!omap keys, where a malicious YAML document burns CPU superlinearly in the number of map entries. First complete release is 4.3.1; the advisory notes the CVE-2026-59870 fix was never backported to 3.x.

Nothing vulnerable ever shipped

js-yaml reaches the tree as eslint → js-yaml — development scope — and it does not appear in the committed build/index.js (verified: 0 references). The bundle is byte-identical before and after this change, so this owes no version bump and require-version-bump should pass without one.

How the gap was found, and why it is worth writing down

The advisory fired on apple-mail-mcp, which already had a js-yaml override — pinned at ^4.2.0, a floor written for an earlier advisory and below this fix. That is the failure mode worth naming: a caret range does not protect against an out-of-date floor. The caret stops the tree moving backwards; it never moves it forwards onto a newer fix. So an override can sit in the file looking like protection while enforcing a version that is no longer safe — the mirror image of the fast-uri: 3.1.4 exact-pin-became-a-ceiling incident already documented beside it.

The other three repos carried no js-yaml entry at all, so all four are floored here in one pass.

Verification

• js-yaml@4.3.1 resolved in all four lockfiles, with the override present in the lockfile's own overrides: section — the only proof an override is actually live.
• 4.3.1 published 2026-07-31, so it is 7 days past the repos' 1440-minute minimumReleaseAge soak. No minimumReleaseAgeExclude carve-out was added.
• pnpm audit: no known vulnerabilities in all four.
• Bundle hash unchanged in all four.
• lint / typecheck / test / format:check clean — 449 (mail), 519 (notes), 111 (numbers), 290 (photos).