build(deps): group the vitest packages across all update types

[bgard68]

Stops #182/#183 from recurring on the next vitest major. Pairs with #189, which is the one-commit fix for the instance that already happened.

The gap

The npm entry groups ["minor", "patch"] only:

groups:
  npm:
    patterns: ["*"]
    update-types: ["minor", "patch"]

So a major bypasses the group and arrives as one PR per package. @vitest/coverage-v8 pins vitest with an exact peer dependency, so splitting a vitest major across two PRs guarantees two permanently-red branches — each fails npm ci with ERESOLVE against the other's version, and no rebase can help.

The fix

A vitest group with no update-types filter, so it spans all bump sizes:

groups:
  vitest:
    patterns: ["vitest", "@vitest/*"]
  npm:
    patterns: ["*"]
    update-types: ["minor", "patch"]

Order matters: Dependabot assigns a dependency to the first group whose patterns match, so vitest must precede the catch-all.

This is the same reasoning the file already applies to github-actions, quoting its existing header comment: codeql-action's sub-actions must run the same version, and that constraint "holds regardless of whether a bump is major, minor or patch." The vitest pair has exactly that property.

Verification

• yaml.safe_load parses the file; 9 update entries, unchanged from before.
• Group order confirmed ['vitest', 'npm'], with vitest carrying no update-types filter.
• Only additive — 11 insertions, no existing line modified. Non-ASCII characters in the surrounding comments verified intact (no mojibake).

🤖 Generated with Claude Code