test: migrate test runner from web-test-runner to vitest

[danyill]

Replace @web/test-runner with vitest in browser mode (Playwright/Chromium). All 574 tests pass; no test logic changed.

• Swap chai's expect for vitest's built-in expect across all 63 spec files (mechanical import change only).
• Add vitest.config.ts: browser mode, v8 coverage, coverage enabled by default. Use isolate: false to avoid an iframe-load race in @vitest/browser 4.x that intermittently dropped random test files (single-worker modes deadlock, so they aren't an option).
• Ratchet coverage thresholds to current values with autoUpdate; they sit just below 100% only because v8 counts branches more strictly than the istanbul instrumentation web-test-runner used.
• Drop web-test-runner deps (@web/*, chai, mocha, concurrently); add vitest, @vitest/browser(-playwright), @vitest/coverage-v8, playwright.
• Remove stray tGSE/canAddSampledValueControl.ts (a misplaced duplicate; the real file lives in tSampledValueControl/).
• Ignore vitest browser-mode failure artifacts (.vitest-attachments, screenshots).

Closes #152

[stee-re]

wow!! that happened fast!
Have you tried debugging failing tests? What was your experience? In my earlier trials with vite/vitest for OpenSCD plugins where I was forced to use Playwright, it caused me to back out of Vitest entirely.
When I mentioned trying vitest with scl-lib, it was because scl-lib has no Web components or GUI (so no sendMouse commands). It was therefore my hope & expectation, we could avoid browser mode entirely. I think the performance hit you take in browser mode, removes a lot of the attraction to using Vitest. But the deal breaker for me was debugging in Browser mode. This felt like it was a step in the wrong direction (when compared to WTR).
Don't get me wrong, I really think its worth while to figure this out. WTR seems to have stagnated. Contributed fixes are years waiting to be PR'd, merged and released. So I see WTR as a liability, but Vitest for standard plugin development has proven a hard nut to crack.
Did you look into using Vitest (NOT in Browser mode) using jsdom to give us the needed XML API support?

[stee-re]

I'm really really hoping we can avoid Browser mode.

[danyill]

I'm looking into this. I'm not sure JSDOM has the XML handling capability we need at this time (see e.g. this jsdom/jsdom#1775)