Minimum browser support

Given that we have a (seemingly) viable fix, I'd propose that we:

- Incorporate this fix, and the browser notice feature, into the next regularly scheduled RC
- QA our minimum supported browser versions thoroughly with these in-place
- If we encounter significant problems, consider bumping the minimum supported version immediately rather than investing resources into fixing them.
- Adopt a longer-term policy for browser support (i.e. last two LTS releases for Firefox, ~2 years for Chrome, something simple like that).
- In the next regularly scheduled RC after that one, bump the minimum supported browser versions to some minimum that matches the policy

Does that sound reasonable? If so, I'd like help with ensuring these two PRs are reviewed, QA'd, and included in the next RC. Then perhaps we can schedule a meeting to discuss our longer-term policy.

After those steps, we can shore up our browser support CI testing:
- Add a CI job that runs a subset of our e2e tests against the minimum supported browser on each PR
- Add a CI job that runs all e2e tests on all major supported browser versions, on a nightly or weekly basis with a high number of retries, so that we get advanced notice of version-specific within our supported range

I discovered recently that CircleCI has a browser-tools orb for installing browsers that should make this easier, so we can replace our custom "download browser" step.

cc @Gudahtt

Start by reviewing the current e2e CI setup and the custom browser-download step, then identify how the browser notice and minimum-version changes would fit into the next release candidate. Define the supported browser policy, validate the minimum versions across e2e tests, and document the CI jobs and release steps needed for the work to be complete.

Written by the indexing model from the issue text.