build(deps-dev): bump brace-expansion from 1.1.11 to 1.1.18

[dependabot]

Bumps brace-expansion from 1.1.11 to 1.1.18.

Release notes

Sourced from brace-expansion's releases.

v1.1.15

• Backport v5.0.6 change to v1 (#111) 0b09384

---

juliangruber/brace-expansion@v1.1.14...v1.1.15

v1.1.12

• pkg: publish on tag 1.x c460dbd
• fmt ccb8ac6
• Fix potential ReDoS Vulnerability or Inefficient Regular Expression (#65) c3c73c8

---

juliangruber/brace-expansion@v1.1.11...v1.1.12

Commits

• 758fcd6 1.1.18
• 27fbeed Merge commit from fork
• 5c57cc2 1.1.17
• d757f1d npm ignore .claude
• cb4b9e4 fix: backport GHSA-mh99-v99m-4gvg (#129)
• 447763a 1.1.16
• d74e630 fix: v1 backport for CVE-2026-13149 (#122)
• 2203f4f 1.1.15
• 0b09384 Backport v5.0.6 change to v1 (#111)
• 10c05fc 1.1.14
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

• Resolves 2/4 issues in brace-expansion

[sourcery-ai]

Hey - I've found 2 issues

Fixed security issues:

• brace-expansion (link) · Dashboard

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="yarn.lock" line_range="6-68" />
<code_context>
+  resolved "https://registry.yarnpkg.com/@esbuild/linux-s390x/-/linux-s390x-0.18.10.tgz#84318e86ee1e377c603c7b5359f5f67771eddd99"
+
 "@esbuild/linux-x64@0.18.10":
-  "integrity" "sha512-wj2KRsCsFusli+6yFgNO/zmmLslislAWryJnodteRmGej7ZzinIbMdsyp13rVGde88zxJd5vercNYK9kuvlZaQ=="
-  "resolved" "https://registry.npmjs.org/@esbuild/linux-x64/-/linux-x64-0.18.10.tgz"
-  "version" "0.18.10"
+  version "0.18.10"
+  resolved "https://registry.npmjs.org/@esbuild/linux-x64/-/linux-x64-0.18.10.tgz"
+
+"@esbuild/netbsd-x64@0.18.10":
+  version "0.18.10"
</code_context>
<issue_to_address>
**🚨 issue (security):** The regenerated Yarn lockfile removes every `integrity` checksum, including entries whose `resolved` URL has no hash fragment. Release workflows using `yarn install --frozen-lockfile` therefore no longer verify those downloaded tarballs against a digest committed to the repository.

**Triggers:** When dependencies are installed by the prerelease or publish workflows using Yarn.

**Suggested fix:** Regenerate the lockfile with integrity migration enabled and retain the SHA-512 `integrity` fields.
</issue_to_address>

### Comment 2
<location path="yarn.lock" line_range="193-197" />
<code_context>
+  version "10.0.1"
+  resolved "https://registry.npmjs.org/@types/mocha/-/mocha-10.0.1.tgz"

 "@types/node@^18.15.1":
-  "version" "18.15.2"
+  version "18.19.130"
+  resolved "https://registry.yarnpkg.com/@types/node/-/node-18.19.130.tgz#da4c6324793a79defb7a62cba3947ec5add00d59"
+  dependencies:
+    undici-types "~5.26.4"

 "@types/semver@^7.3.12":
</code_context>
<issue_to_address>
**issue (testing):** The Yarn lockfile now resolves `@types/node` to 18.19.130 and adds `undici-types`, while the unchanged npm lockfile used by CI still resolves 18.15.2. CI therefore validates a different TypeScript dependency graph from the one used by the prerelease and publish packaging workflows.

**Triggers:** When CI installs with `npm ci` but release packaging installs with `yarn install --frozen-lockfile`.

**Suggested fix:** Keep the unrelated `@types/node` resolution unchanged, or update both lockfiles together and validate the Yarn-based release dependency graph in CI.
</issue_to_address>

Fix all in Cursor

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

🚨 issue (security): The regenerated Yarn lockfile removes every integrity checksum, including entries whose resolved URL has no hash fragment. Release workflows using yarn install --frozen-lockfile therefore no longer verify those downloaded tarballs against a digest committed to the repository.

Triggers: When dependencies are installed by the prerelease or publish workflows using Yarn.

Suggested fix: Regenerate the lockfile with integrity migration enabled and retain the SHA-512 integrity fields.

Fix in Cursor

[sourcery-ai]

issue (testing): The Yarn lockfile now resolves @types/node to 18.19.130 and adds undici-types, while the unchanged npm lockfile used by CI still resolves 18.15.2. CI therefore validates a different TypeScript dependency graph from the one used by the prerelease and publish packaging workflows.

Triggers: When CI installs with npm ci but release packaging installs with yarn install --frozen-lockfile.

Suggested fix: Keep the unrelated @types/node resolution unchanged, or update both lockfiles together and validate the Yarn-based release dependency graph in CI.

Fix in Cursor