Fusion gene overlap: renamed symbol side and annotation race lose the 5' partner from gene lists

🤖 Written by Claude

Follow-on to #1506. A gene list node for the 5' partner of a fusion could miss it, for two separate reasons. Both are fixed on master; this issue is for manual testing.

## 1. Renamed gene symbols (ACPP -> ACP3)

On vg-test2, analysis 55 holds ACPP::ETV1 (variant 16929494). A gene list node for ETV1 (node 615) found it, one for ACP3 (node 614) did not.

DRAGEN wrote the old symbol `ACPP`. A `GeneSymbol` row for ACPP still exists (Ensembl uses it), so the symbol matcher returned it directly and the HGNC previous-symbol rename to ACP3 was never applied. The side was stored as a custom `FusionGeneId` with no HGNC and no genes, and no RefSeq release knows `ACPP`, so no `VariantGeneOverlap` row was written for that side.

Fixed in 27c7910ff: a side is resolved by its breakpoint position against the release's transcripts first, then by HGNC previous/alias symbols; the genes it landed in are stored on `FusionGeneId.genes` and the annotation reads those before falling back to the symbol. Plan: `claude/plans/1506_fusion_gene_resolution_plan.md`.

Fusions loaded before that commit keep their old identity - re-load the AllFusions.csv to get the new one.

## 2. Gene-level annotation racing the upload pipeline

After re-loading, the new variant (16983779, identity ACP3 = HGNC:125) had no annotation at all. The upload pipeline kicks the annotation scheduler as soon as the variants exist (`CheckStartAnnotationTask`), but the `GeneFusion` rows are written by `DragenTSO500AllFusionsInsertTask`, which runs after the genotype insert. A gene-level run dispatched straight away found no `GeneFusion` rows and finished as an empty success. Timing dependent - for the same range, the GRCh37 run annotated 0 and the GRCh38 run annotated 12.

Fixed in 4d0e375c1: the gene-level run creates the `GeneFusion` rows itself from the Variant (idempotent, so the upload step still finding them is fine).

## Manual test

1. Load an AllFusions.csv containing a fusion whose partner is written under an old HGNC symbol (e.g. ACPP::ETV1).
2. Check the variant's gene-level annotation exists for every build (both `VariantAnnotation` symbol shows the approved symbol, e.g. `ACP3::ETV1`, and `VariantGeneOverlap` has a row for each partner).
3. In an analysis on that sample, a gene list node for the approved symbol (ACP3) and one for the other partner (ETV1) both find the fusion.
4. Repeat the load a second time - the fusion still annotates (no race with the InsertTask).

On vg-test2 the empty runs for the reloaded files were deleted; the scheduler recreates them, after which variant 16983779 should carry overlaps for ACP3 (gene 55) and ETV1 (gene 2115).

Start with the manual test on vg-test2 using analysis 55 and an AllFusions.csv containing ACPP::ETV1; the relevant plan is claude/plans/1506_fusion_gene_resolution_plan.md. Reload the data, repeat the load, and verify ACP3 and ETV1 annotations, overlaps, and gene-list results for every build without an annotation race.

Written by the indexing model from the issue text.