Score set page 504s for score sets with about 500k variants #451

Problem

The score set page can't load a score set with over ~200k variants, for example urn:mavedb:00000053-a-1 (score set id 183). GET /score-sets/{urn}/variants builds the whole lean variant list, serializes it with Pydantic and sends it as one JSON body. The load balancer times out before the first byte, returns 504, and the worker process stays busy until the response is finished.

Indexing is necessary but not enough. With the variant-number sort indexed (#899) and a (mapping_record_id, allele_id) WHERE valid_to IS NULL index on mapping_record_alleles for get_protein_hgvs_by_record, the endpoint still 504s for score sets in our database. The remaining cost grows per row: join fan-out, serialization and transfer before anything is sent.

Scope

• Stream GET /score-sets/{urn}/variants as NDJSON in batches, following _stream_score_set_variant_details in routers/score_sets.py. get_lean_score_set_variants (lib/score_set_variants.py) yields batches instead of a list.
• Add the mapping_record_alleles (mapping_record_id, allele_id) WHERE valid_to IS NULL index, built by hand before the deploy and issued without CONCURRENTLY in its migration (Squash the migration history into one baseline so it replays from an empty database #877's rule).
• Update the ui's score set page to consume the stream.
• If the ui still can't render 500k rows once they arrive, file the server-side histogram and heatmap aggregation as a follow-up.

Acceptance criteria

• urn:mavedb:00000053-a-1's page loads in staging with no 504.
• The first bytes of the response arrive within 5 seconds for a 500k-variant score set.
• Peak api memory for the request doesn't grow with the variant count (spot-checked).
• The streamed rows are identical to today's JSON rows for a small score set.