Complete brace-expansion sequence bounds

[jjoanna2-debug]

Summary

• Completes the dev-only brace-expansion remediation by lifting the CommonJS-compatible v1 floor from 1.1.17 to 1.1.18 and the independent v5 path from 5.0.8 to 5.0.9.
• Adopts both releases only after they cleared the repository 1440-minute minimumReleaseAge gate, with no minimumReleaseAgeExclude and no audit suppression.
• Records the completed sequence-path bound under CHANGELOG [Unreleased]; the shipped bundle remains byte-identical.

Verification

• pnpm install --frozen-lockfile — lockfile passes supply-chain policies (369 entries).
• pnpm test — 29 files, 408 tests passed.
• pnpm run lint — 0 errors; 10 pre-existing warnings.
• pnpm run typecheck.
• pnpm run format:check.
• pnpm run build.
• SHA-256 before/after build: build/index.js 5e68e0d25b68475052acd9d1d39a6b8e7c1fb43f0723d8457c5b4fcbf96e12af; build/cli.js b26026b4ba98c49ee6074b836ef917b5e6d348e6cddc741943db2f902bca8617.
• git diff --exit-code -- build/.
• git diff --check.

Risk / Notes

• Public-facing CHANGELOG.md changes under [Unreleased].
• Dev-toolchain dependency only; no runtime source, runtime dependency, package version, or shipped bytes change.
• Closes brace-expansion: lift to 1.1.18 / 5.0.9 once they clear the 24h minimumReleaseAge gate #121 after merge.

[sweetrb]

Merged — thanks @jjoanna2-debug, and thanks especially for holding this to the 24-hour gate rather than reaching for a minimumReleaseAgeExclude carve-out. Pulling a one-hour-old brace-expansion release behind an exclusion is exactly the scenario the gate exists to prevent, and "wait a day" was the right call for a dev-only advisory that isn't in the shipped bundle.

The 10,000-zero pad in your repro harness was the detail that made this checkable. My own 60-character measurement showed only a ~30% RSS difference and I couldn't reproduce your magnitudes; the missing parameter turned it into 4,606 ms → 9 ms and 176 MB → 61 MB, with byte-identical final output. That's what separated "the diff plainly adds a bound" from "the bound demonstrably matters", and it's why this landed on evidence instead of on the advisory text — which is still wrong in both directions (GitHub lists 5.0.8 as first-patched, and its <= 5.0.7 range marks the entire v1 line vulnerable under semver).

Two things I pushed to your branch before merging:

A floor for the v5 line. The lift moved v5 to 5.0.9, but only by re-resolution — brace-expansion@<1.1.18 doesn't match 5.0.8 under semver, so nothing actually pinned that result. Both majors now carry an explicit two-sided floor. They have to be two-sided: a bare <5.0.9 also matches 1.1.18, and would force minimatch 3's CommonJS path onto the v5 ESM API — the same expand is not a function failure that made the v1 backport necessary in #119.

One [Unreleased] security entry instead of two. Neither had shipped, so the release notes would have carried "deliberately partial, deferred until the gate clears" directly above "completed" for the same version.

Your finding also turned out to be bigger than this repo. Checking the siblings for #121's last checklist item: all three resolve a third major (minimatch@9 → v2) that mail doesn't have, and two of their four paths (1.1.16, 5.0.7) were below even the advisory's floor. Ported with three floors each — sweetrb/apple-notes-mcp#113, sweetrb/apple-numbers-mcp#49, sweetrb/apple-photos-mcp#60.