fix(deps): clear high-severity audit findings

[Astro-Han]

Summary

• clear all critical and high findings reported by dev-dep-audit
• update the direct Sharp pins and refresh every vulnerable brace-expansion major without forcing incompatible versions
• add a narrow gray-matter compatibility patch so Bun can enforce the safe js-yaml release

There is no related issue; this PR follows up directly on the audit failure observed while merging #1529.

Why

The repository-wide audit was blocked by 10 findings across tar, brace-expansion, fast-uri, js-yaml, and sharp. The vulnerable tar path is runtime-reachable through Arborist package installation, while the remaining findings also fail the required dependency gate.

Bun 1.3.14 only supports top-level overrides. A global js-yaml@4.3.0 override is required to replace an exact vulnerable transitive pin, but gray-matter@4.0.3 still calls the removed safeLoad and safeDump aliases. The committed patch changes only those aliases to their equivalent load and dump APIs and records the compatible dependency range.

Related Issue

None. This is a direct CI security-audit follow-up to #1529.

Human Review Status

Pending

Review Focus

• the root override boundary for tar, fast-uri, and js-yaml
• the two-line gray-matter API compatibility patch
• the lockfile retaining safe brace-expansion releases for majors 1, 2, and 5
• Sharp 0.35.3 optional binaries across macOS, Windows, and Linux

Risk Notes

• Sharp 0.35 removes deprecated APIs and requires Node.js 20.9 or newer. Current call sites use supported metadata, resize, trim, composite, and PNG APIs; Electron 40 and CI satisfy the Node floor.
• gray-matter is patched because Bun cannot express a path-scoped js-yaml override. A regression test covers both parsing and stringification.
• No visible UI or copy changed, so no manual visual check was needed.
• Dependency and platform impact was checked on macOS locally; a cold reviewer also verified frozen install resolution for macOS arm64/x64 and Windows arm64/x64. Full cross-platform jobs remain delegated to PR CI.

How To Verify

bun install --force --frozen-lockfile: passed; committed patch applies from a clean reinstall
bun audit --audit-level=high: passed with zero findings
bun pm why: brace-expansion resolves to 1.1.16, 2.1.2, and 5.0.8; tar 7.5.21; fast-uri 3.1.4; js-yaml 4.3.0; sharp 0.35.3
bun --cwd packages/opencode test test/config/markdown.test.ts: 38 passed
bun --cwd packages/desktop-electron test scripts/generate-icons.test.ts: 10 passed
bun turbo typecheck --filter=@opencode-ai/core --filter=opencode --filter=@opencode-ai/app --filter=@opencode-ai/desktop-electron: 9 tasks passed
bun --cwd packages/app build: passed
bun --cwd packages/desktop-electron build: passed
Cold review: no P0/P1; frozen install dry-runs passed for macOS arm64/x64 and Windows arm64/x64

Screenshots or Recordings

Not applicable; there are no visible UI changes.

Checklist

How to use this checklist:

• Tick a box by replacing [ ] with [x]. Do not edit, add, or remove items.
• The bot-applied label items can only be honestly ticked AFTER the PR is opened and the labeler / priority-triage bots have run — return to the PR description and tick them then.
• Most items are required. The few that are conditional are explicitly marked (conditional); for those, leave unticked if they truly do not apply and explain why in Risk Notes. All other items must be ticked before requesting human review.

• Type label — this PR carries exactly one of bug, enhancement, task, documentation. Type labels are author-added; the labeler bot does NOT assign them. Add the label in the GitHub UI, then tick this.
• Routing labels — this PR carries at least one of app, ui, platform, harness, ci. The labeler bot assigns these on PR open based on changed paths. Confirm the bot's choice (or override if wrong), then tick this.
• Priority label — this PR carries exactly one of P0, P1, P2, P3. The priority-triage bot suggests one on PR open. Confirm or override, then tick this.
• Human Review Status above is set to Pending, Approved by @<reviewer>, or Not required: <reason> (default is Pending; "not required" is restricted to bot-authored low-risk PRs).
• I linked the related issue, or stated in Summary why there is no issue.
• I described the review focus and any meaningful risks.
• I replaced the example block in How To Verify with the real verification steps and the key result for each.
• I did not introduce unrelated refactors, dependencies, generated files, or file changes beyond the stated scope.
• (conditional) I manually checked visible UI or copy changes when needed, with screenshots or recordings. Leave unticked only if no visible UI or copy changed.
• (conditional) I considered macOS and Windows impact for platform, packaging, updater, signing, paths, shell, or permissions changes. Leave unticked only if no platform/packaging surface was touched.
• (conditional) I called out docs, release notes, dependencies, permissions, credentials, deletion behavior, generated content, or local file changes when relevant. Leave unticked only if none of those surfaces was touched.
• I reviewed the final diff for unrelated changes and suspicious dependency changes.
• I am targeting dev, and my PR title and commit messages use Conventional Commits in English.

[coderabbitai]

Warning

Review limit reached

@Astro-Han, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 25 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 27017bfb-9256-4ec1-8d6f-4fab88278cfa

📥 Commits

Reviewing files that changed from the base of the PR and between 7b3c8a0 and 71f8bed.

⛔ Files ignored due to path filters (1)

• bun.lock is excluded by !**/*.lock

📒 Files selected for processing (6)

• package.json
• packages/app/package.json
• packages/desktop-electron/package.json
• packages/opencode/package.json
• packages/opencode/test/config/markdown.test.ts
• patches/gray-matter@4.0.3.patch

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/dev-dep-audit-high

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Suggested priority: P2 (includes non-doc, non-test paths outside the low-risk bucket).

P1/P0 are reserved for maintainer confirmation. Please relabel manually if this is a release blocker, security issue, data-loss risk, or updater/runtime failure.