chore: bump the vitest trio to 4.1.11 past GHSA-82fw-gwwq-j7x9 (dev-only moderate)

[cliffhall]

Summary

npm audit at 2.6.0 release time reported a moderate, dev-only advisory against the vitest stack, in the root and clients/web installs:

GHSA-82fw-gwwq-j7x9 — Vitest: Path Traversal / Arbitrary File Read via @vitest/mocker Redirect Mock
Affects @vitest/mocker 2.1.0 – 4.1.10, and everything depending on it (vitest, @vitest/coverage-v8, @vitest/browser, @vitest/browser-playwright).

The fix is the 4.1.11 patch. It did not gate the 2.6.0 release — npm audit --audit-level=high exits 0 in all five installs — so it was deliberately deferred out of #2300 rather than forced on release day.

Why it is not a one-line bump

Per AGENTS.md, vitest, @vitest/coverage-v8 and web's @vitest/browser-playwright are pinned exactly and must move together. Editing all three to 4.1.11 bumps the root install cleanly, but clients/web then fails to resolve:

npm error Conflicting peer dependency: vitest@4.1.11
npm error   peer vitest@"4.1.11" from @vitest/browser-playwright@4.1.11

@vitest/browser-playwright declares an exact peer on vitest, and web does not declare vitest itself — its copy is the peer shadow described in AGENTS.md. Web's lockfile pins that copy at 4.1.10, and neither npm install nor npm update will move it: the exact peer plus the lockfile form a knot npm resolves by refusing.

Deleting clients/web/package-lock.json does clear it — but regenerating re-resolves every caret range in web's tree at once:

• 298 "version" lines changed
• package count 649 → 657

That is an uncontrolled dependency update, not a security patch, and it is far too broad to review inside a release-prep PR. Hence this issue.

What to try

1. An overrides entry in clients/web/package.json pinning vitest to 4.1.11, leaving the rest of the lockfile untouched — the approach AGENTS.md already prescribes for a transitive that will not move (clients/cli pins @types/node this way).
2. Failing that, a surgical hand-edit of the vitest constellation's entries in web's lockfile (vitest, @vitest/browser, @vitest/browser-playwright, @vitest/mocker, @vitest/runner, @vitest/snapshot, @vitest/spy, @vitest/utils, @vitest/pretty-format), followed by npm install to verify integrity.
3. If neither is clean, consider whether the 5.0.0 major is the better target — but that is its own issue, not this one.

Whichever lands, the acceptance below is what matters: the three pins move together, and the churn stays confined to the vitest packages.

Acceptance

• vitest, @vitest/coverage-v8 (root) and @vitest/browser-playwright (web) all read 4.1.11
• npm audit reports no @vitest/mocker advisory in the root or web installs
• Lockfile churn is confined to the vitest constellation — no unrelated transitive re-resolution
• npm run verify:dep-lockstep passes
• npm run local:gate passes

Context

Found during the 2.6.0 release audit (#2300). The hono advisories reported in the same sweep were fixed there, since hono is a runtime dependency of core/.