refactor: migrate to vite-plus unified toolchain

[setchy]

closes: #3028

[netlify]

✅ Deploy Preview for atlassify canceled.

Name	Link
🔨 Latest commit	4262e5f
🔍 Latest deploy log	https://app.netlify.com/projects/atlassify/deploys/6a4c28788755a40009032774

[setchy]

note 0.2.1 needs some manual migration steps: see https://github.com/voidzero-dev/vite-plus/releases/tag/v0.2.1

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[setchy]

@copilot let's review this PR

[Copilot]

@copilot let's review this PR

Here's my review of the vite-plus migration:

Overall: The migration looks clean and well-executed. Key items are correctly handled:

✅ vite-plus@0.2.2 installed (0.2.2 > 0.2.1 migration requirements)
✅ @voidzero-dev/vite-plus-test fully removed — not present in package.json, lockfile, or any source files
✅ vite.config.ts now imports defineConfig and Plugin from vite-plus directly and consolidates lint, fmt, and staged configuration
✅ package.json scripts updated to use vp check, vp lint, vp fmt, vp test
✅ Direct vitest usage (Case B): vitest@4.1.9, @vitest/coverage-v8@4.1.9, and @vitest/ui@4.1.9 are all pinned consistently — no duplicate vitest versions in the lockfile
✅ No browser-mode vitest (project uses node + happy-dom environments only, so no extra @vitest/browser-playwright pin is needed)
✅ No stale peerDependencyRules referencing vitest or the old wrapper

One thing worth verifying: The v0.2.1 migration guide specifies keeping a vite → npm:@voidzero-dev/vite-plus-core override in pnpm-workspace.yaml. This project doesn't have that override (the lockfile shows vite@8.1.3 resolving as the real Rolldown-based Vite, not an alias to vite-plus-core). Since all config imports come from vite-plus directly rather than from vite, and the plugins peer-depend on vite@8.x which is already Rolldown-based, this appears intentional. Worth confirming with vp check that no warning is raised about this.

Everything else is in order — the migration follows the 0.2.1 upgrade guide for a node-mode project with direct vitest usage.