[jakebromberg]

Closes #3740

Step 3 of #3738. Adds the catalog search schema as migration 0209_catalog-search-schema. Nothing reads or writes the new tables yet.

What changed

• library_track_index (library_id integer PK, FK library.id ON DELETE CASCADE; search_doc tsvector) with a GIN index on search_doc. This is the narrow table the matcher reads.
• library_track_data (library_id PK, same FK; source, source_batch, discogs_release_id, tracks jsonb, fingerprint, refreshed_at). A record has a row in both tables or in neither. This follows the 2026-11-04 plan-revision comment on Migration: catalog search schema (library_track_index table, label and alternate-name trigram indexes) #3740, which supersedes the single-table design in the issue body.
• Trigram GIN indexes library_label_trgm_idx and library_alternate_artist_name_trgm_idx on library. They are created with a hand-added IF NOT EXISTS, and the migration header carries the exact CREATE INDEX CONCURRENTLY commands for the production pre-build (per docs/migrations.md). The new tables' own indexes are plain, since the tables are empty.
• tests/mocks/database.mock.ts gets doubles for both tables, as check:db-mock-sync requires.

label stays out of search_doc, no tracks column is added to library, and the 500-character title cap is left to the future writer job. Ops builds the two trigram indexes on production before this merges; no production command was run from this PR.

Size: about 46 added lines of production source in schema.ts (much of it comments); the rest is the generated migration and snapshot, tests, and the mock.

Acceptance criteria and how each is tested

• Migration applies cleanly, header holds the CONCURRENTLY commands: applied through dev_env/init-db.mjs (the same runner CI and deploy use) against a fresh Postgres; npm run lint:migrations passes with 0 warnings.
• GIN index on library_track_index.search_doc and both trigram indexes exist after a fresh migrate: tests/integration/library-track-index-schema.spec.js checks each is a valid gin index on the expected column.
• The foreign keys cascade on delete: same spec inserts a library row plus a row in each new table, deletes the library row, and asserts both are gone. It also asserts that an orphan library_id is rejected (23503) on both tables.
• npm run ci:testmock: not run. Docker was not running on the machine and starting Docker Desktop would take over the screen. Instead I ran the integration spec against a private Homebrew PostgreSQL 18 cluster (migrated and seeded via dev_env/init-db.mjs). The repo's other local checks pass: typecheck, format:check, lint:changed (0 errors), check:db-mock-sync, lint:migrations, and the unit suite (761 suites, 16534 tests). Please let CI's integration job confirm.

Mutation check: dropping the two indexes and replacing one cascade FK with a plain FK makes three of the six cases fail. I did not mutate the orphan-rejection cases (they pass on any FK), and did not mutate library_alternate_artist_name_trgm_idx separately; it uses the same assertion path as the label index.

Mirrors: tests/mocks/database.mock.ts (hand-maintained double, enforced by check:db-mock-sync); meta/applied-hashes.json and the journal were updated by the repo's scripts.

[github-actions]

Schema constraint shape report

Probed: automated prod RDS snapshot 2026-11-04T05:04:37.447000+00:00, restored to ephemeral sandbox for run 41954231923 (schema wxyc_schema), before the pending migrations were applied.

This PR adds:

• could not derive SELECT — CHECK (source IN ('compilation', 'override', 'album_metadata')) (library_track_data_source_check)
• query failed: relation "wxyc_schema.library_track_data" does not exist — FOREIGN KEY (library_id) REFERENCES library(id) on library_track_data
• query failed: relation "wxyc_schema.library_track_index" does not exist — FOREIGN KEY (library_id) REFERENCES library(id) on library_track_index

one or more probes failed; see above. The check status is non-blocking.