feat: Implement CatVRS transit layer on variant endpoints

[bencap]

Context

Depends on: #742, #743

For protein-level assayed variants, the MAVE score applies to a category of nucleotide variants, not to any specific nucleotide variant directly. CatVRS (GA4GH Categorical Variation Representation Specification) is the right vocabulary for communicating this to API consumers and the UI.

CatVRS is used as a transit layer only — storage remains in the alleles table. CatVRS lives exclusively in API responses.

Data model traversal

To build a CatVRS response for a protein-level AssayedVariant:

1. Find the current MappingRecord for the AssayedVariant where assay_level = protein
2. Traverse mapping_record_alleles to find all associated Allele rows where level = 'coding'
3. Each coding-level Allele row (with its annotation data from the per-type annotation tables) becomes a CatVRS member
4. The implied score is inherited from the AssayedVariant — it is categorical, not directly measured

Goal

Implement CatVRS response objects on variant endpoints per the API contract defined in #743, making it semantically clear to consumers that scores on coding-level alleles are implied (categorical) rather than directly measured.

Acceptance Criteria

• Pydantic CatVRS schemas defined for categorical variant representation
• GET /variants/{id} returns a categoricalVariants field for protein-level assayed variants, populated from associated Allele rows where level = 'coding'
• Score set variant endpoint supports CatVRS expansion per the decision in spike: Design variant + annotation API shape for score set and variant pages #743
• CatVRS objects correctly express that scores are implied (inherited from the protein-level assayed variant), not directly measured
• Annotation data for each coding-level Allele is included per the API design decision
• Single variant response time meets the target defined in spike: Design variant + annotation API shape for score set and variant pages #743