Develop E2E tests to run in BrowserStack

[rwood-moz]

Add initial set of E2E tests for Webmail that will run against the local dev environment. In future git issues have the same test suite run in CI against PRs, as well as nightly in BrowserStack on desktop and mobile browsers.

[rwood-moz]

E2E tests were added by @Sancus in #18 (awesome!) so changing this issue to enable the existing E2E tests to run in BrowserStack (create a new nightly E2E test job to run on Firefox on OSX and Chromium on Win11 to start; more desktop and mobile platforms to follow later).

[rwood-moz]

After spending lots of time reviewing the existing E2E tests and trying to get them running in BrowserStack, here's the situation:

First, the existing Stormbox E2E tests run against the local Stormbox stack and share the same dependencies as stormbox itself. Stormbox itself is using node 24 (from /.node-version) and "@playwright/test": "1.60.0". That works great when running the E2E tests locally and in CI against the local Stormbox stack/containers (as they run now).

Unfortunately BrowserStack doesn't support @playwright/test 1.60. I've contacted BrowserStack support and they confirm it is not supported (I tried it anyway, and verified it doesn't work). So we would need to downgrade to @playwright/test 1.59. However, there is a known Playwright issue with Node 24 and @playwright/test <= 1.59: the playwright browsers fail to download (hangs at 100%). I verified this is the case: I changed our @playwright/test version to 1.59.0, but the existing E2E tests in CI fail because the E2E tests job hangs when attempting to download the playwright browsers. The playwright issue is fixed in @playwright/test 1.60+ but as mentioned above we cannot use that since BrowserStack doesn't support it. The playwright issue also only happens with Node 24:16+ which Stormbox is using. We could pin the Stormbox node version to 24:15 however I don't see that as acceptable.

Secondly, outside of that blocking issue, I don't believe that we could even get the existing E2E tests running against stage and production anyway because they are very tightly coupled with the Stormbox stack. They are excellent tests but they are really more like integration tests: they use the Stormbox UI but they also make a lot of direct JMAP calls, access the local cache, make local DB queries, etc. They're designed to run against and make use of a local Stormbox stack.

I think the best solution to move forward here is to develop a totally separate and slimmer set of E2E tests to run in BrowserStack. This separate E2E test suite would use their own dependencies that BrowserStack supports (could use their own docker container), and be UI driven so that they can run against Stormbox/Webmail on stage and production. The existing E2E tests wouldn't be touched and would continue to run against the local Stormbox stack in CI.

This solution would mean having two sets of E2E tests to maintain, but given the above issues I am thinking this is probably the best way forward here.