vite-plus peers @vitest/browser-playwright at an exact 4.x, so browser-mode projects cannot adopt Vitest 5

## Summary

Every published `vite-plus` peer-depends on `@vitest/browser-playwright` (and `@vitest/browser-webdriverio`) at an **exact** 4.x patch. `@vitest/browser-playwright@5.0.0` in turn requires `vitest@5.0.0`. So a project that uses Vitest **browser mode** through Vite+ cannot adopt Vitest 5 until a `vite-plus` release peers a 5.x provider.

Is Vitest 5 support planned, and is there an issue to follow?

## The pins

```
$ npm view vite-plus@ peerDependencies

vite-plus@0.2.8: { "@vitest/browser-playwright": "4.1.10", "@vitest/browser-webdriverio": "4.1.10" }
vite-plus@0.2.9: { "@vitest/browser-playwright": "4.1.10", "@vitest/browser-webdriverio": "4.1.10" }
vite-plus@0.3.0: { "@vitest/browser-playwright": "4.1.11", "@vitest/browser-webdriverio": "4.1.11" }
vite-plus@0.3.1: { "@vitest/browser-playwright": "4.1.11", "@vitest/browser-webdriverio": "4.1.11" }
```

The other side:

```
$ npm view @vitest/browser-playwright@5.0.0 peerDependencies
{ vitest: '5.0.0', playwright: '*' }

$ npm view vitest version
5.0.0

$ npm view vite-plus dist-tags
{ test: '0.0.2-…', alpha: '0.1.21-alpha.7', latest: '0.3.1' }
```

`latest` is 0.3.1, so there is currently no release — stable or alpha — whose provider peer admits Vitest 5.

## Why it matters beyond the major

Because the peer is an **exact** version rather than a range, even a *patch* bump of the provider needs a matching `vite-plus` release. That is the mechanism behind #2531 (0.2.9 pinning `vitest@4.1.10` while the provider resolved to 4.1.11) — the 0.3.x line moved the pin from `4.1.10` to `4.1.11` and cleared that particular mismatch, but the exact-pin shape that produced it is unchanged.

Would a caret range (`^4.1.11`) be viable for the provider peers, so provider patches don't require a `vite-plus` release? I appreciate there may be a bundled-copy/singleton reason for the exact pin — if so it would be useful to have that written down, since from the outside it reads as something that could be loosened.

## Context

A Vue 3 + Vitest browser-mode project on pnpm, just migrated from standalone Vitest to `vp test` on 0.3.1. The migration itself went cleanly; Vitest 5 was the one thing we had hoped it would unblock, and it is held on this pin alone.

Start by inspecting the vite-plus package peerDependencies and the published versions referenced in the issue, then compare them with @vitest/browser-playwright@5.0.0 and @vitest/browser-webdriverio. Review #2531 for the reason behind the exact pins. Done means a documented, compatible release path for Vitest 5 and provider patch updates, with the relevant package checks passing.

Written by the indexing model from the issue text.