chore: bump the vitest group with 4 updates [AR-89256]

[mmurawski-dn]

Summary

Supersedes #694, whose CI failed after the vitest 5 upgrade (vitest, @vitest/coverage-v8, @vitest/browser-playwright → v5.0.0, vitest-browser-react → v2.3.0):

• Type Check failure: ds-split-button test passed a RegExp to toHaveTextContent, which is now typed string | number-only in vitest 5's browser matchers.
• Test failures: vitest 5 split the browser-mode toHaveTextContent jest-dom matcher into an exact-match-only assertion plus a new toMatchTextContent for partial/RegExp matching (see the vitest browser assertions docs). Every test that relied on the old partial-match default (checking a select trigger's text alongside its icon, a table row's text alongside other cells, a tooltip listing several names, etc.) needed to switch to toMatchTextContent.
• Similarly, getByRole/getByText locators now need exact: false passed explicitly to get substring name matching that used to be the default (affects ds-toggle, ds-table-header-ellipsis, ds-time-picker).
• One more failure was a real interaction-order issue: ds-table-editable hovered a reveal-on-hover lock icon (pointer-events: none until the parent cell is hovered) directly, which the upgraded Playwright's stricter actionability check now rejects. Hovering the parent cell first (mirroring how a real pointer reaches the icon) fixes it.
• Two more instances of the same toHaveTextContent/RegExp issue (ds-avatar-group, ds-comments-drawer) were introduced by commits that landed on main after chore: bump the vitest group with 4 updates #694 was opened; fixed here too since this PR is rebased on current main.

Added a patch changeset for @drivenets/design-system, matching this repo's convention for dependency-bump PRs (see .github/scripts/generate-dependabot-changeset.ts).

Test plan

• tsc (full package, not just affected) — 0 errors
• All 12 previously-failing test files now pass in isolation and together
• Lockfile updated via a scoped pnpm update (matches dependabot's own diff shape — only vitest and its direct transitive deps changed, no incidental churn)

https://claude.ai/code/session_01FruzGJAvphgB11ptUBPrBt

---

Generated by Claude Code

[netlify]

✅ Deploy Preview for drivenets-design-system ready!

Name	Link
🔨 Latest commit	fa0dc2a
🔍 Latest deploy log	https://app.netlify.com/projects/drivenets-design-system/deploys/6aa0052bc6fca40008fce130
😎 Deploy Preview	https://deploy-preview-700--drivenets-design-system.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[mmurawski-dn]

Check Unused Code and Dependencies failed with pnpm dedupe --check finding duplicate transitive resolutions (@babel/types, picomatch, flatted, ws, etc.) left over after the scoped vitest bump. Pushed a pnpm dedupe commit to clean those up — this mirrors the dedupe step dependabot's own automation runs after a bump (.github/workflows/dependabot-side-effects.yml). Re-verified tsc and the full set of previously-fixed browser tests still pass on the deduped lockfile.

---

Generated by Claude Code

[mmurawski-dn]

Pushed a second round of fixes for Test failures on the previous commit — same root cause as before (vitest 5's stricter exact-match defaults for getByRole/getByText), just in more components than the original PR's CI run exercised: DsMainMenu, DsTopBarNavigation, DsDropdownMenu, DsFileUpload, DsKeyValuePair, DsBreadcrumb — all render an icon glyph as literal text right next to a label, so exact: false is needed to match. Also fixed DsPanel's width tests (same getByText issue) and one DsMainMenu tooltip-hover test needing { force: true } for a stricter Playwright actionability check.

One failure I'm leaving as-is: ds-comment-bubble.browser.test.tsx > should call onClose when close button is clicked in thread. I reproduced it locally against both vitest 5 (this PR) and vitest 4.1.10 (current main, unmodified) — it fails identically both ways, so it predates this PR and isn't caused by the dependency bump. I wasn't able to root-cause it (tried userEvent.click and waiting on document.fonts.ready, neither changed the outcome) and didn't want to guess at a product-level fix blind. This will likely still show red on this PR's Test job since it's a single aggregated command — flagging it explicitly here rather than leaving it unexplained. Happy to file this as its own issue if useful.

Re-verified tsc (0 errors) and all touched test files green (94/94) before pushing.

---

Generated by Claude Code