tests: cover the VA annotation routes across variant shapes, not one fixture variant

[bencap]

Summary

A reviewer of the MaveMD manuscript hit download fail: network error on one variant's annotation download while a different variant downloaded successfully. The failure never reproduced and our tests could not have caught it because every happy-path assertion for the three /va/ routes exercises a single variant from a single fixture score set. Parameterize these routes across variant shapes so shape-dependent failures surface during testing CI.

This issue is about closing the test coverage gap. The reviewer's report is the motivating case, not a reproduction target.

Problem

• tests/routers/test_mapped_variants.py is genuinely thorough on error paths. Multiple mapped variants, none, no mapping data, insufficient evidence. But every success case requests #1 (or #2) of one fixture score set.
• One variant shape leaves whole classes of input untested: protein-level vs nucleotide-level assay, indels, synonymous / no-change HGVS, non-coding targets, multi-target score sets, and variants missing gnomAD or ClinVar enrichment.
• The reviewer's symptom matters diagnostically: axios reported Network Error rather than a server message, meaning no HTTP response reached the browser at all. That points to an unhandled 500 or a gateway timeout rather than any of the handled 404 paths those tests cover so carefully.
• Net effect: a variant-shape-dependent 500 can ship, and it reaches users as a download button that silently fails for some variants and not others.

Proposed behavior

• Parameterize /{urn}/va/study-result, /{urn}/va/functional-statement, and /{urn}/va/pathogenicity-statement over a matrix of variant shapes rather than one fixture variant per route.
• Add a contract-level assertion across the whole matrix: every (route, shape) pair returns either a response validating against the route's declared response model, or a handled 4xx carrying a detail body. Never a 5xx, never an unhandled exception.

Acceptance criteria

• Each of the three VA routes is exercised over at least these shapes: nucleotide-level assay variant, protein-level assay variant, indel, synonymous / no-change, non-coding target, variant with no gnomAD record, variant with no ClinVar control.
• For every (route, shape) pair the response is a 2xx validating against the route's response model, or a 4xx carrying detail.
• No (route, shape) pair produces a 5xx.
• The matrix is data-driven: adding a shape does not require writing a new test function per route.

Implementation notes

• Routes are in mavedb/routers/mapped_variant.py; the pathogenicity-statement route is served by the handler named for the ACMG evidence line. Existing tests are in tests/routers/test_mapped_variants.py.
• The shape matrix needs more fixture flexibility than the current per-test score set construction gives. Decide and adopt a test object construction strategy (factory_boy vs scenario builders) #782 (factory_boy vs scenario builders) is an important consideration here. We should either settle it first, and perhaps use it as our first case, or build the matrix behind a construction helper that can be retargeted once Decide and adopt a test object construction strategy (factory_boy vs scenario builders) #782 is decided and implemented..
• Reviewer context for provenance: reported 15 May 2026, one variant failing while another succeeded on the same annotation type.