chore(deps): refresh undici to 7.29.0

[jasonworden]

Refreshes undici 7.28.0 → 7.29.0 in pnpm-lock.yaml, clearing all five open undici Dependabot alerts.

Alerts cleared

Alert	Severity	Advisory
#34	High	GHSA-4cwx-7wf7-3272 — cross-user information disclosure and parse-time crash via degenerate private cache directives
#37	Medium	GHSA-m8rv-5g2x-5cg5 — CRLF injection via blob-like body type property
#36	Medium	GHSA-jr45-8vmc-qm54 — cross-user information disclosure via whitespace around equals in Cache-Control directives
#35	Medium	GHSA-v3r7-h72x-cjcm — cookie attribute injection via unsanitized domain and unparsed setCookie fields
#33	Medium	GHSA-8xcm-r25x-g524 — downstream response desynchronization via retry interceptor

All five share the same vulnerable range (>= 7.0.0, < 7.29.0) and the same first patched version, 7.29.0.

Why a lockfile refresh is the whole fix

undici@7.28.0
└─┬ cheerio@1.2.0
  └─┬ @vscode/vsce@3.9.2
    └── mermaid-lint-vscode@0.14.0 (devDependencies)

cheerio@1.2.0 declares undici: ^7.19.0, so the declared range already admits 7.29.0 — the lockfile was simply stale. pnpm update undici -r resolves it, and no manifest range bump or overrides: entry is needed.

Exposure

Dev-only. The single path runs through @vscode/vsce, the VS Code extension's packaging tool, which is a devDependency of mermaid-lint-vscode. Nothing published reaches undici — the released packages ship files: ["dist", "index.ts"] and never include the lockfile.

No version bump

Consistent with #107, #117, and #174: the lockfile is not published, so consumers resolve the patched transitive dep themselves and a bump would publish identical tarballs.

Verification

• pnpm test — 25 files, 1230 tests passing
• pnpm lint — clean (84 files)
• Diff is 4 lines in pnpm-lock.yaml, all undici resolution entries

🤖 Generated with Claude Code