test(e2e): give the suite a throwaway database of its own (#186)

The e2e suite ran against the development database and nothing truncated it. Every run seeded more fixtures and left them, so the unfiltered storefront grew monotonically — 1,662 items by the time #186 was filed — until rendering it outran the assertions' timeouts. It failed locally, passed in CI where the database is fresh, and got steadily worse, which is the combination nobody can act on.

start-local.ps1 -E2eDb runs the stack against a separate container on a separate port with tmpfs storage, so it starts empty every time. Migrations already run on every start, so an empty volume is a working one. The development database is untouched, so anything set up there by hand survives.

Deliberately a third database rather than sharing either existing one. The integration suite truncates between tests, so an e2e run sharing with it would have its fixtures deleted underneath it (#116) — different container, different port, different credentials, so the mistake is impossible rather than discouraged.

Verified by recreating the database from the compose file, confirming it came up with zero items, and running the full suite against it: 157 of 157. An earlier attempt at this reported 23 passed and 53 not run, which was worthless — a stale backend from a previous run still held port 3000 and was talking to a database I had already deleted. The port is checked before the run now, and the same mistake produced a wrong rate-limiter measurement earlier in this work.

Pagination is the other half of #186 and is filed separately: a shop that renders its whole catalogue in one page is worth fixing on its own merits, not as a side effect of a test fix.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

scripts/run-tests.ps1

@@ -18,7 +18,15 @@
     integration  Backend Jest integration tests against a disposable Postgres.
                  Brings the container up itself.
     e2e          Frontend Playwright tests. Needs the app stack up; start it
-                 with .\scripts\start-local.ps1 first.
+                 with .\scripts\start-local.ps1 -E2eDb first.
+
+                 -E2eDb matters. Without it the suite runs against the
+                 development database, which nothing truncates: every run seeds
+                 more fixtures and leaves them, the unfiltered storefront grows
+                 monotonically, and eventually rendering it outruns the
+                 assertions' timeout. It then fails locally, passes in CI where
+                 the database is fresh, and gets worse (#186). With it, the
+                 stack runs against a throwaway database that starts empty.
     all          All three, in that order — cheapest and most isolated first,
                  so a failure that a later suite would also show up in is
                  reported by the suite that localises it best.