Seed the two legacy cross-reference tables

[jakebromberg]

Closes #2391

artist_crossreference and artist_library_crossreference were empty in every dev database while carrying rows in production. Nothing local exercised their read path, and a consumer rendering "there are no cross-references" emitted that claim unconditionally -- a broken query looked exactly like correct behaviour.

What is seeded

Five artist cross-references and two release cross-references, over three new artists (John Coltrane, Alice Coltrane, Duke Ellington) and one new library row.

The relationships are real, and so is the filing situation they record. Coltrane played tenor on Kind of Blue, which the seed already files under Davis; the Ellington and Alice Coltrane pairings are the canonical case of a release credited to one artist and filed under another, which is what artist_library_crossreference exists to express. Miles Davis was already a fixture, so the artist cross-references reach existing seeded data rather than forming an island.

Ids are resolved by name

Artist ids come from a sequence. A literal id breaks the moment a row is added above it, and breaks silently -- the cross-reference attaches to whichever artist landed on that id, which still satisfies every foreign key.

That resolution has a cost the literal ids did not: on a re-run a name matches both the original row and the duplicate the same run just inserted. Every insert is therefore guarded -- NOT EXISTS where the table has no unique constraint to conflict on (artists, library), ON CONFLICT DO NOTHING where it does.

Verification

Docker was unavailable locally, so the full init-db.mjs pipeline was not run here; CI's integration job is the first end-to-end execution.

What was verified: the new block was extracted verbatim from seed_db.sql and executed against a PostgreSQL 18.6 database built with the same constraints the real schema declares (artist_genre_key, artist_crossref_source_target, library_id_artist_id, and both foreign keys). It applied cleanly and produced the expected 5 and 2 rows with the name resolution linking correctly to the pre-existing Miles Davis fixture.

Idempotency was verified by running the block three times against a fresh database: all three runs succeeded and the counts did not move (artists 4, library 2, genre xrefs 3, artist xrefs 5, release xrefs 2). An earlier revision failed on the second run -- that is what prompted the guards.

Placement

The block sits before the library.artist_name backfill at the end of the file, so the new library row is picked up by it. Placed after, the row would have carried a null artist_name and been invisible to both the tsvector and trigram search paths.

Also

Seed verification now prints both cross-reference counts alongside the existing ones, so an empty table is visible at seed time rather than at the point some screen renders nothing.

[github-actions]

Schema constraint shape report

no schema or migration changes detected in this PR

[jakebromberg]

Not ready: the new CI gate immediately caught a real failure

Marking this draft. The workflow change works -- and the first thing it did was fail.

Before the gate fix, Integration-Tests reported success in 14 seconds without executing the seed. After it, the job ran for 2m39s and tests/integration/flowsheet-upcoming-show.spec.js failed:

● V2 flowsheet upcoming_show enrichment (BS#1607)
  › cold read batches the lookup ...; warm reads are served from cache

  expect(afterWarm - afterCold).toBeLessThan(BATCHED_SCAN_CEILING)
  Expected: < 7
  Received:   9

It failed on both attempts in the same run, so it is not a flake in the ordinary sense -- though the assertion's own comment records observed values of 4-6 against a ceiling of 7, so its headroom is one unit.

What is and is not established

The counter reads seq_scan + idx_scan on concerts only. This PR's seed touches artists, library, genre_artist_crossreference and the two artist cross-reference tables -- not concerts. The spec's fixed ids (artists and albums 1-3) are untouched; the new artists append at 10-12.

So the mechanism is not obvious, and I have not established one. Two candidates worth checking, neither confirmed:

1. artist_crossreference carries an AFTER STATEMENT touch_library_watermark trigger. This seed fires it, so the library watermark now moves during seeding where it previously did not.
2. Three more rows in artists (9 to 12) and one more in library could tip a planner choice on tables this small, which is the variance the ceiling comment already describes.

Docker was unavailable on the machine this was written on, so the failure could not be reproduced locally to distinguish them.

What that means for this PR

The gate change is doing its job: this failure was reachable from main before and nothing would have reported it. But the seed cannot merge while it makes an existing spec fail, and the honest options differ enough to be worth a decision rather than a guess:

• confirm the watermark hypothesis and adjust the seed so it does not fire the trigger;
• treat the ceiling as too tight and raise it with evidence, which weakens an anti-N+1 guard;
• split the gate fix into its own PR so the CI gap closes now, and land the seed behind it.

Not retrying CI -- the failure is deterministic and retries would only spend minutes.