perf: reduce Supabase egress from E2E test runs

[zacharias-ona]

Context

The Supabase free plan includes 5 GB egress/month. In the Apr 21–25 period, egress hit ~12.47 GB (7.47 GB overage) driven by ~133 PRs merging in 5 days during the database feature rollout. Each PR triggers 2+ full E2E runs against production Supabase (Feature Builder + Post-Merge Verifier), and the suite has grown to 310 test cases across 64 spec files.

The spike correlates directly with PR volume and is expected given the current setup — not a bug. But there are optimizations worth considering if egress remains a concern.

Optimization opportunities

1. Replace listUsers({ perPage: 1000 }) with profile lookup

13 of 24 database E2E specs call admin.auth.admin.listUsers({ perPage: 1000 }) to find the test user. workspace-limit.spec.ts already does it efficiently via profiles.select("id").eq("email", ...). Apply the same pattern to all database specs.

2. Cache test user ID resolution

Every spec independently resolves the test user ID. A shared fixture, helper module, or TEST_USER_ID env var would eliminate ~50+ redundant queries per run.

3. Run a subset of E2E tests post-merge

The Post-Merge Verifier runs all 310 tests after every merge. With high-volume days (38 merges), that's ~11,800 authenticated page loads/day. Options:

• Run only specs affected by the merged PR's changed files
• Run a smoke subset post-merge, full suite on a schedule

4. Dedicated Supabase project for E2E

All environments share the production Supabase instance. A separate test project would isolate E2E egress from the production billing quota.

Impact estimate

Items 1–2 are low-effort, low-risk. Items 3–4 require more thought about tradeoffs (test coverage confidence vs. cost).