Add score_set_id to the allele-centric mapping tables before they ship #833

Summary

RT's mapping_records links to its score set only through variants, which has millions of rows. A policy that goes through variants to find the score set takes about 700 ms to return 16 rows. This issue adds score_set_id to mapping_records and mapping_record_alleles on the RT branch, before 2026.3.0 ships, while the tables are still new and empty in production.

Terms are defined in the glossary on #808. RT is the allele-centric mapping work on feature/bencap/allele-centric-mapping-and-storage.

This has to merge into the RT branch before 2026.3.0 ships. After that it's a large-table backfill.

The change

1. Build a unique index on variants (id, scoreset_id) by hand in production before the deploy, since migrations can't run CONCURRENTLY (Squash the migration history into one baseline so it replays from an empty database #877):

   CREATE UNIQUE INDEX CONCURRENTLY IF NOT EXISTS uq_variants_id_scoreset ON variants (id, scoreset_id);

2. A new migration at the head of the RT branch. RT's migrations have already run on staging, so the change can't go into the migration that creates the tables. It:

   • creates the same index with IF NOT EXISTS and without CONCURRENTLY, which does nothing where it was built by hand;
   • adds score_set_id to mapping_records, backfills it from variants, sets it NOT NULL, and adds a unique index on mapping_records (id, score_set_id);
   • replaces the single-column variant_id foreign key with FOREIGN KEY (variant_id, score_set_id) REFERENCES variants (id, scoreset_id), since variants keeps its older column name;
   • does the same for mapping_record_alleles, backfilled from mapping_records, with FOREIGN KEY (mapping_record_id, score_set_id) REFERENCES mapping_records (id, score_set_id) ON DELETE CASCADE.

   The backfills are sized for staging. In production the tables are empty when it runs.

3. Update both ORM models so score_set_id is required, and set it wherever rows are created: the mapping job, reverse translation, and the reshape script feat: Retroactive backfill — migrate MappedVariant data and run reverse translation for existing score sets #747 uses.

The foreign key covers both columns so a row can't point at one score set's variant while claiming another, public score set.

mapped_variants doesn't get the column. It stays without RLS until #747 drops it (#832).

Acceptance criteria

• mapping_records.score_set_id and mapping_record_alleles.score_set_id exist, NOT NULL, under two-column foreign keys.
• A test asserts inserting a mapping record whose score_set_id doesn't match its variant's is rejected.
• The mapping job, reverse translation and feat: Retroactive backfill — migrate MappedVariant data and run reverse translation for existing score sets #747's reshape script set score_set_id on every row.
• The migration upgrades and downgrades on a staging-shaped database, with the hand-built index present and absent.