test(e2e): stabilize software-rendered browser runs

[PaulHax]

What changed

• Reduce local e2e concurrency from six Chrome instances to three.
• Restore the default render/download timeout from 20 to 30 seconds.
• Run Linux CI in native headless mode with an explicit ANGLE/SwiftShader backend.
• Remove the Xvfb setup from the Linux workflow.

Why

Six software-rendered Chrome instances can starve the browser and WebDriver long enough for otherwise healthy views to exceed the 20-second render timeout. Timed-out pages recovered without a reload once CPU pressure eased.

The Ubuntu CI failure was a separate browser problem: Chrome lost its WebGL contexts after they were created, and the vtk.js shader errors were follow-on failures. Explicitly selecting the SwiftShader backend avoids leaving renderer selection to Chrome's fallback path. This also avoids masking failures with broad spec retries.

Tested

• npm run test:e2e:chrome — 30/30 spec files passed after rebasing on current main
• Chrome 150 full Linux/headless suite — 30/30 spec files passed
• Chrome 150 segment-group-download — 10 consecutive passes
• Chrome 150 large-session stress spec — 3 consecutive passes
• Prettier, ESLint, and TypeScript checks

[netlify]

✅ Deploy Preview for volview-dev ready!

Name	Link
🔨 Latest commit	2c6aa0c
🔍 Latest deploy log	https://app.netlify.com/projects/volview-dev/deploys/6a723133f4e9d6000841c318
😎 Deploy Preview	https://deploy-preview-917--volview-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

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