Shortcomings with E2E tests

Our E2E tests ostensibly have the following general goals:

- User journey validation (test key flows like workspace creation)
- Regression detection
- Production simulation (concurrent use, use components together to accomplish a task)

The tests cover each of these to some extent, but there are a number of key shortcomings which we should address - especially as the size of our team increases, institutional knowledge/memory becomes more dispersed, and our velocity ramps up.

## Lack of Terraform integration

Terraform is, let's face it, the core of our product. None of our E2E tests actually make use of Terraform, instead relying on the "echo" provisioner which mocks out responses.

## Lack of resilience / general flakiness / error handling

The tests are peppered with short timeouts to overcome races, brittle selectors used, lack of error handling or clear diagnostic logging.

## Authoring & troubleshooting

It's not possible to use the full gamut of Playwright's tools without a headed browser, which we don't currently (or maybe can't) make use of in our dogfood workspaces. Writing these tests therefore becomes tedious with a lot of learning required, and we should have a step-by-step guide for common troubleshooting tasks and reference implementations for the best tests to ~get Claude Code to rip off~ take inspiration from.

---

The purpose of this issue is not to throw shade on any individual(s); I didn't even `git blame` who owns most of the code.

We need to get this test suite under control before the tech debt starts becoming too expensive to service.

This test suite is our last line of defence besides for manual dogfooding, which is obviously sub-optimal in terms of time and reproducibility.