Get rid of jasmine-maven-plugin

Evaluation of the cost of moving all the Jasmine tests away from jasmine-maven-plugin (done while trying to add a JS unit test for XWIKI-25222).

What has to move

Only 2 modules still use jasmine-maven-plugin, both only in the integration-tests-chrome profile, which CI never activates (livedata doesn't use it anymore):

So since nothing runs them, both suites have rotted, and any solution starts by repairing them.

The CKEditor specs create real CKEditor 4 instances (iframe editing area, selection, snapshots): jsdom cannot handle that reliably, so this module needs a real browser whatever the solution. The web-war specs (Prototype/jQuery logic, events bridge, suggest) should run under jsdom, except maybe exporter.js (615 lines, drives jsTree), which is the main risk on that side.

What CI already does

Measured on the last master "Build for Main" (CI #9021, 2h21, build scan x5dlxpcy4eupm):

• Vitest with jsdom, e.g. xwiki-platform-notifications-webjar: Node install 4.7s, pnpm install 1.7s, Vitest step 5.3s.
• Playwright in a real browser already runs on CI: the test:unit script of xwiki-platform-bootstrap runs playwright install chromium && playwright test. The step takes 32s: ~25s to download Chromium and 6s of tests. Its Playwright spec simply opens the unchanged QUnit HTML suite and reads the results, which is exactly the pattern needed to run the Jasmine specs as they are.
• xwiki-platform-web-war currently takes 71s, 62s of which is the Closure minification. No JS test runs.

Option 1: Vitest (what this issue asks for)

Vitest with jsdom for web-war, Vitest browser mode with Playwright (@vitest/browser, not in the pnpm catalog yet) for CKEditor.

The CKEditor unpacking step is the pom.xml / package.json duplication mentioned in a previous comment.

Option 2: keep the Jasmine specs and run them with Playwright

Same pattern as bootstrap/QUnit: a standalone Jasmine runner page, the webjars unpacked from the Maven dependencies, and a single Playwright spec loading the page and checking the results.

• Cost: ~2-3 days of setup, 2-4 days of repairs, ~1 day of cleanup, so 5-8 dev-days.
• Pro: dependencies stay in Maven, so no duplication.
• Con: we keep the old Jasmine style, every test needs a browser, and it goes away from the Vitest direction of the platform.

Added CI time

The TestRelease stage runs with skipTests so it shouldn't be impacted (IT stages not checked in detail).

Proposal

A mix of both: Vitest with jsdom for web-war, and for CKEditor pick between Vitest browser mode and the bootstrap-style wrapper after trying both. Start with a 1-2 day web-war prototype based on the locationPicker.js test written for XWIKI-25222, to validate these estimates.

Note: the dev-days are estimates; only the CI timings are measured.