build(deps-dev): upgrade vitest to v5

[claude]

Requested by David Sanders · Slack thread

This bumps vitest and @vitest/coverage-v8 to ^5.0.1. That also fixes the existing peer mismatch between coverage-v8 4.1.2 and vitest 4.1.11. Vitest 5 lists vite as a required peer instead of a dependency, so I added vite as a devDependency at ^8.0.16, the version already in the lockfile. No test or config changes were needed. Lint, build and build:docs pass locally. 86 tests pass, the same as main. The 5 tests that fetch from github.com (FetchDownloader.network.spec.ts and one downloadArtifact() test in index.spec.ts) couldn't reach GitHub from my environment on either branch. I checked separately that Vitest 5 still serializes HTTPError in the format their inline snapshot expects.

🤖 Generated with Claude Code

https://claude.ai/code/session_01N2vvE5XzurMvQfsX7Vz7bF

---

Generated by Claude Code

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​vitest/​coverage-v8@​4.1.2 ⏵ 5.0.1			+1	-1
	vitest@​4.1.11 ⏵ 5.0.1	+1		+1
	vite@​8.0.16

View full report

[claude]

Looks good, straightforward dependency bump.

What was reviewed: package.json devDependency changes (vitest and @ vitest/coverage-v8 to ^5.0.1, new vite ^8.0.16) and the corresponding yarn.lock regeneration. Confirmed the lockfile entries resolve to matching versions (5.0.1 / 8.0.16) with consistent peer dependency declarations. No application source under src/ or test/ is touched, and no security-sensitive surface is involved.

Extended reasoning...

This is a devDependency-only version bump (vitest/@ vitest/coverage-v8 to ^5.0.1, plus new explicit vite ^8.0.16 devDependency) with a regenerated yarn.lock; no source or test files changed. Verified the lockfile entries for vitest, @ vitest/coverage-v8, and vite resolve consistently at the stated versions with matching peer dependency metadata. The bug hunter reported no findings, the change is small and mechanical, and it touches no auth/crypto/permissions code, so this qualifies for approval without requiring human review.