Rename ResolvedVariantInfo.c_hgvs to resolved_hgvs

🤖 Written by Claude

`ResolvedVariantInfo.c_hgvs` holds whatever HGVS we resolved for that build. When there's no usable transcript — a g.HGVS-only submission, or a variant that runs off the transcript — that value is a `g.99087902A>C`. The column name makes it look like it might be a c.HGVS but it could be g.HGVS

We have already renamed `CHGVS` → `HGVSDisplay` in #1063 and the `HGVSComponents` split in #1702.

#1702 left this out because it needs a migration and the naming question deserved its own decision.

## Rename

| now | after |
|---|---|
| `ResolvedVariantInfo.c_hgvs` | `resolved_hgvs` |
| `ResolvedVariantInfo.c_hgvs_compat` | `resolved_hgvs_compat` |
| `ResolvedVariantInfo.c_hgvs_converter_version` | `hgvs_converter_version` |
| `ResolvedVariantInfo.c_hgvs_converter_data_version` | `hgvs_converter_data_version` |
| `ImportedAlleleInfoValidation.c_hgvs_37` / `c_hgvs_38` | `resolved_hgvs_37` / `resolved_hgvs_38` |
| `Classification.chgvs_grch37` / `chgvs_grch38` (+ `_compat`) | `resolved_hgvs_grch37` / `resolved_hgvs_grch38` (+ `_compat`) |

The `Classification.chgvs_*` four are properties (`classification/models/classification.py:611-635`) reading straight through to the renamed columns, so they travel with them.

`resolved_hgvs` is redundant on a model already called `ResolvedVariantInfo`, but it earns that in the ORM paths — `grch37__resolved_hgvs` says more in a DataTables column string than `grch37__hgvs`, and it pairs against the existing `ImportedAlleleInfo.imported_hgvs`.

## Keeps its current name

- **`ImportedAlleleInfo.imported_c_hgvs` and `imported_g_hgvs`.** These are two genuinely different inputs — a lab submits under one evidence key or the other, and validation differs by which. `imported_c_hgvs` really does only ever hold a c.HGVS.
- **The `c_hgvs` EvidenceKey** (`SpecialEKeys.C_HGVS`). It's part of the import/export contract with labs, and it's the lab-submitted value, so it means exactly what it says.

Worth noting the end state has a `c_hgvs` evidence key sitting next to a `resolved_hgvs` column. That's the point: they're different things, and today's shared name hides that.

## One column rather than a c/g pair

`resolved_hgvs` stays a single column rather than splitting into `c_hgvs` + `g_hgvs`:

- **The resolver produces exactly one value per build.** `recalc_c_hgvs` (`classification_variant_info_models.py:216`) is a single `result.hgvs_variant.format()` call. A pair would leave one side always NULL, with an "exactly one of these is set" invariant that nothing enforces.
- **The discriminator already exists.** `ResolvedVariantInfo.transcript_version` is a nullable FK set during the same resolution, and `_calculate_validation` already uses it for exactly this question:
```python
both_builds_have_transcript = all(
build_info and build_info.transcript_version_id for build_info in (normalised, lifted)
)
```
A c/g column split would duplicate what that FK already carries, and let the two disagree.
- **Consumers are kind-agnostic.** After #1702, `HGVSComponents` parses `c.`/`g.`/`n.`/`p.` uniformly, so display, sort, diff and export all just want "the HGVS for this build". A pair would push a `c_hgvs or g_hgvs` coalesce into every query path, mirroring the `imported_hgvs` property that already has to paper over the imported pair.
- Storing a g.HGVS *alongside* a c.HGVS for the same build stays available if it's ever wanted — it's derivable on demand from `self.variant`, so it'd be a cache rather than a reason to split now.

## Scope of the sweep

The `RenameField` migration is the small part.

- ~53 ORM lookup paths across Python and templates.
- `ImportedAlleleInfo.column_name_for_build()` (`classification_variant_info_models.py:541`) defaults `suffix='c_hgvs'` and stitches build + suffix into lookup strings. 9 call sites, mostly DataTables configs and `classification_search.py`.
- Those strings reach the browser as DataTables column keys, so CSS selectors follow — e.g. `.dt-grch37__c_hgvs` in `classification/templates/classification/imported_allele_info.html:13`.
- Tests referencing the field by name, e.g. `classification/tests/models/test_imported_allele_info.py`.

Places that want transcript-based records specifically should read `transcript_version_id` rather than infer it from the value, which is clearer than the current arrangement regardless of the column name.

Start with the resolver and lookup entry points in classification_variant_info_models.py:216 and :541, then inspect classification/models/classification.py:611-635 and the referenced template and tests. Rename the listed fields and dependent ORM, DataTables, CSS, and test references, add the required migration, and confirm the existing model tests pass.

Written by the indexing model from the issue text.