fix: retry flaky Playwright integration/e2e tests on CI

[miohtama]

Why

PR #1288's CI repeatedly failed on 3 tests in tests/integration/trading-view/vaults/datasets.test.ts (the vault-datasets API-key flow) — a different overlapping subset each run — while they pass reliably locally. This is long-standing: the CI workflow itself notes (since 2023) that the integration suite is "too flaky and do not pass on CI at all", and build's needs: test is commented out because of it.

Root cause (reproduced, not guessed): the integration suite drives the whole app against a single-process vite preview server whose APIs are served by an in-process mock middleware (vite-plugin-mock-dev-server). Under the parallel-worker load CI applies, that shared server intermittently mishandles a request. The captured failure snapshot shows the form displaying "The API key is not valid" after submitting the valid key — i.e. the mock returned 401 for a correct key under contention. It's environmental, not an app bug.

Reproduced locally by running the file under --workers=4 --repeat-each=8: 7/176 runs failed with the exact CI symptom. Re-running the identical stress with --retries=2: 0 hard failures (all flakes self-recovered).

The integration/e2e Playwright configs had no retries set, so CI ran with 0 retries — any single transient blip failed the whole job.

Lessons learnt

• The integration harness shares one preview+mock process across all Playwright workers. Parallel load causes occasional request mishandling (here: a valid API key mock-rejected with 401). Treat integration/e2e flakiness on CI as environmental contention first; reproduce with --workers=N --repeat-each=M before suspecting app code.
• Retries are the standard mitigation for inherently flaky server-backed e2e/integration suites — but only on CI. Keep retries at 0 locally so genuine regressions surface immediately instead of being masked.
• The failure surfaces as either a 5s assertion timeout or a spurious "API key not valid" error — both trace back to the same shared-server contention, so a deterministic waitForResponse in the test would not have fixed the 401 case; retrying does.
• If the flakiness needs eliminating at the source later, the lever is reducing contention (e.g. fewer integration workers) or a more concurrency-robust mock, not the app.

Summary

• Added a shared ciRetries constant in tests/helpers.ts (process.env.CI ? 2 : 0) with a comment documenting the root cause.
• Wired retries: ciRetries into all three Playwright configs: tests/integration/playwright.config.ts, tests/integration/private.playwright.config.ts, and tests/e2e/playwright.config.ts.
• No app/source changes — test-infrastructure only.

🤖 Generated with Claude Code