Run API tests against a dedicated test database

[tgerke]

Summary

Fixes the dev-DB pollution flagged during the Python workbench work: every pnpm check run left fixture studies and per-study DuckLake catalog schemas (ducklake_st_snap_*) in the shared dev database — 53 of them were manually cleaned out once already, and they regrow on each run.

• apps/api/vitest.config.ts: sets DATABASE_URL to a derived test database (_test appended to the name, so edc → edc_test) and LAKE_DATA_PATH to data/lake-test for all test workers.
• src/test/global-setup.ts: drops and recreates the test database fresh on every run and wipes the test lake dir, then runs migrations once (per-file runMigrations calls become no-ops under the existing advisory lock). Refuses to drop any database whose name doesn't end in _test.
• TEST_DATABASE_URL overrides the derivation entirely.
• CONTRIBUTING documents the behavior.

Behavior notes

• No DB server running: global setup warns and returns; test files skip via their existing reachability probes, exactly as before. On CI an unreachable server is fatal (also as before).
• CI unchanged: the workflow's DATABASE_URL still points at the service container; setup creates edc_test there. The edc user is the cluster superuser in both the compose stack and CI, so CREATE DATABASE needs no new grants.
• Fresh-per-run also removes the slow-flake class where DB-wide scans age over accumulated debris.

Verification

• 209/209 API tests pass locally, twice (second run exercised drop/recreate of an existing edc_test).
• Dev DB ducklake schema count unchanged (2, the demo studies) across runs; the test run's catalog schemas and 26 fixture studies landed in edc_test; parquet debris under data/lake-test (gitignored), data/lake untouched.
• Full pnpm check green.