e2e: first-run spec fails on Next.js cold-start before post-login redirect timeout

# Why?

Playwright's `web/playwright.config.ts` runs with `workers: 1` (sequential execution, separate spec files still run back-to-back against one `next start` server for the whole job). Whichever spec happens to run first alphabetically pays the cold-start cost of the Next.js server's first-ever compile/request, which reliably pushes the post-login redirect past the default 5000ms `expect(...).toHaveURL(...)` timeout used by most specs.

Confirmed reproducible twice in a row on PR #372's Frontend CI (run [31151688282](https://github.com/a2n-seattle/rms-app/actions/runs/31151688282), both the initial run and a full rerun): `batch-crud.spec.ts` (currently first alphabetically) failed identically both times, always as test #1, always ~5.5s, always with the exact same error:

```
Error: expect(page).toHaveURL(expected) failed
Expected pattern: /\/dashboard/
Received string: "http://localhost:3000/test-login"
Timeout: 5000ms
```

Meanwhile the *rest* of that run's failures shifted substantially between the two attempts (different specs failed each time) — the expected signature of shared-fixture/timing flakiness. This one is different: it's fully deterministic, tied to test execution order and server cold-start, not backend state contention. CloudWatch showed no DynamoDB throttling and no Lambda errors during either run, ruling out a real backend issue as the cause.

# What?

Add a warmup step to the e2e suite so the very first spec doesn't pay cold-start latency:

- Add a `globalSetup` in `web/playwright.config.ts` that issues a request against the running app (e.g. `GET /test-login`) and waits for a `200` before Playwright starts executing any spec. This fixes the problem at the root for whichever spec happens to land first, rather than special-casing individual spec files or bumping individual timeouts.
- If a global warmup turns out to be impractical, a fallback would be bumping just the login-redirect assertion's timeout on the affected first-run spec(s) — but this is spec-order-dependent (today it's `batch-crud.spec.ts`, but adding an earlier-alphabetical spec file later would silently move the problem), so the `globalSetup` approach is strongly preferred.

# Testing

N/A — this issue is about e2e test infrastructure itself, not adding application coverage. Verification is confirming CI's e2e job no longer shows this specific cold-start failure signature (test #1 failing at the post-login redirect with the app still on `/test-login`) across a few runs.

# Additional context

Pre-existing e2e test infrastructure debt, not introduced by any specific feature PR — surfaced while investigating a large e2e failure sweep on PR #372 (issue #361). Distinct from #376 and #370, which are both non-deterministic flakiness in specific mid-suite specs; this is a deterministic, execution-order-dependent cold-start gap affecting whichever spec runs first.