Patch vulnerable transitive dependencies with scoped resolutions

[Copilot]

• no schema changes are needed for this pull request

Address the six reported dependency alerts with targeted updates and a Yarn-regenerated lockfile. Preserve the build-infra commit, markdown-it 15.0.1, and separate undici major versions.

• Dependency updates

  Package	Before → after
  joi	18.2.3 → 18.2.9
  smol-toml	1.7.0 → 1.9.1
  undici	7.29.0 → 7.29.1; 8.10.0 → 8.10.2
  js-yaml	5.2.2 / 5.3.0 → 5.4.3
  markdown-it	14.3.0 → 14.3.2; 15.0.1 unchanged
  brace-expansion	5.0.9 → 5.0.12

• Resolution scope
  Override only markdownlint-cli2’s exact smol-toml, js-yaml, and markdown-it pins. Other updates satisfy existing ranges. Verified advisories require later fixes than the suggested joi, smol-toml, and brace-expansion releases; smol-toml 1.9.x retains the parser API used by markdownlint.

• Validation
  Node 24 / Yarn 4.18.0: immutable installation, all eight tests, and parser compatibility checks passed. All eight locked entries and seven installed copies are outside verified affected ranges. Markdown lint passed; external link validation failed on DNS resolution.

• Remaining findings
  Full audit still reports unchanged vulnerabilities in braces, KaTeX, and source-map-js, plus a whatwg-encoding deprecation. None of the six requested packages remains flagged. Read-only review found no significant issues; CodeQL had no analyzable source changes.

[miqui]

security deps fixes

[lornajane]

I am surprised to see this pull request given our AI policy. What is it's origin and how can we ask follow up questions about the purpose of the change?

[miqui]

@lornajane

I am surprised to see this pull request given our AI policy. What is it's origin and how can we ask follow up questions about the purpose of the change?

I received an email notification from GH regarding these sensitive issues. There should be no surprise here. It's good that GH is doing this for the project on our behalf. I then took it upon myself to investigate (in my judgment), fired up my GH Copilot against the repo to fix these, and reviewed everything. I always do. Btw, the learn repo has similar problems.

If you have any questions not already answered in this PR, let me know.

[miqui]

@lornajane

Grokking back on the AI policy:

The policy permits AI-assisted contributions with disclosure and human accountability(which I believe I have done), while prohibiting AI-generated issue comments, discussion replies, and PR descriptions. Nothing in it specifically bans contributing dependency security fixes. Perhaps here I could have done a better job in the original text/comments added by my agent (following my instructions).

[handrews]

@miqui I don't understand why we wouldn't fix this upstream in build-infra?

[handrews]

@miqui I had GPT look at this PR and whether the fix belongs here or in build-infra, and it belongs in build-infra with some caveats.

GPT-written explanation (provided due to our general position that using AI is the only way our build infra work is going to get done):

---

I think this should primarily be fixed in OAI/build-infra, rather than in this repository.

OpenAPI-Specification has only one direct JavaScript dependency: @oai/build-infra. Every package addressed here comes from that dependency tree:

Packages	Introduced through
joi, js-yaml	Linkspector
smol-toml, js-yaml, markdown-it	markdownlint-cli2
undici	Cheerio and Node/Puppeteer tooling
brace-expansion	Minimatch in the tooling tree

Adding these resolutions here would make OpenAPI-Specification responsible for build-infra's transitive dependencies. We would also need equivalent overrides in every other specification repository using build-infra, potentially giving each consumer a different dependency graph. Avoiding that duplicated dependency maintenance is one of the reasons build-infra was introduced.

There is one complication: copying this resolutions field into build-infra would not itself fix consumers. Yarn applies resolutions from the top-level project and does not impose a dependency package's resolutions on consumers.

The preferable process is:

1. Update ranged dependencies and direct parent packages in build-infra.
2. Qualify the resulting build-infra commit against its consumers.
3. Refresh each consumer with yarn up -R @oai/build-infra.

The exact dependency pins need additional consideration. Current markdownlint-cli2 0.23.3 still pins smol-toml 1.8.0 and js-yaml 5.4.1. If those exact versions remain affected and markdownlint-cli2 has no corrected release, build-infra would need to consider a patched/forked dependency, replacing the CLI with direct use of the markdownlint API, or documenting temporary top-level consumer resolutions as a short-lived workaround.

This PR is also based on the older build-infra commit 53b4eb3 and intentionally preserves it. Current build-infra main has already upgraded parts of this dependency tree, including markdownlint-cli2 from 0.23.2 to 0.23.3. That makes part of this PR stale, although additional build-infra work may still be needed for the remaining exact pins.

My recommendation is to supersede this PR with a build-infra change, followed by normal downstream dependency refreshes. If temporary consumer resolutions are unavoidable, they should be coordinated across all build-infra consumers rather than introduced only here.

[miqui]

TDC: should be fixed: primarily be fixed in OAI/build-infra. Closing this PR. @miqui todo: will focus on build-infra instead.