Fixture factories + scratch pool for integration tests

[chiptus]

Parent

#64

What to build

Extend the integration-test harness (#280) with fixture factories so tests can create scoped data without hand-writing inserts and cleanup, and stay safe under parallel test workers.

• Factory functions (e.g. create-artist, create-set, create-user) that insert via the real Supabase client, return the created row's id, and self-register with the harness's shared cleanup hook so nothing needs to be manually deleted.
• Every factory generates a uniquely-named/scoped row (no two tests ever touch the same row), rather than relying on shared mutable seed data.
• A pool of disposable "scratch" rows for common simple cases, so not every test needs to build a full dependency graph from scratch.
• Proven by an integration test for a hook that reads data the test itself creates (e.g. a hook scoped to an edition/artist/set), demonstrating that running it repeatedly or in parallel produces no collisions and leaves no residue.

Acceptance criteria

• At least two fixture factories exist (e.g. artist and set), each returning the created row's id and auto-registering for cleanup.
• A scratch-row pool exists for at least one common case.
• Running the proving integration test twice back-to-back (or concurrently) produces no collisions and leaves the database in the same state it started in.
• No test in this ticket hand-writes its own insert/delete cleanup code — everything goes through the factories.

Blocked by

• Integration-test tier scaffold + harness core, proven by useGenresQuery #280 (integration-test tier scaffold + harness core)