Variant details samples grid - IGV link per sample, loading that sample's BAM

🤖 Written by Claude

Split out of #49 (*Variant Details improvements*, 2018), where it was raised as:

> * Make a second IGV link at the samples (for when you have no bams in any)
> * Add IGV link to jump to sample bams (if they have it)

The rest of #49 is either done or not worth doing — see that issue.

## What we have now

The variant details page has one IGV link, in the links box (`vc_links.js:generateIgv` → `createIgvUrl(locus)`).
With no BAM function it falls through to `noBamsHere`, so it's a plain `goto` — IGV jumps to the locus with
whatever tracks the user already had loaded. `variant_details.html:63` has a stub `getBams()` returning `[]`.

That covers the "no bams anywhere" case. What's missing is jumping to a *sample's* BAM from the samples grid.

## Proposed

An IGV link per row in the variant details samples grid, which loads that sample's BAM(s) and goes to the locus —
i.e. the `load` op that `create_igv_url` already builds when it's handed files.

Only draw the link for rows that have a BAM. Most deployments have none (`SampleFilePath` is populated by seqauto,
or by hand), so a column of dead links would be noise. If no row in the grid has one, leave the column out entirely.

### Data

`SampleFilePath` with `file_type=BAM` — `Sample.get_bam_files()` (`snpdb/models/models_vcf.py:541`), the same source
`AnalysisNode.get_bams_dict()` (`analysis/models/nodes/analysis_node.py:302`) uses for the analysis grid's IGV links.

One query for the samples we're already building rows for, added to `_build_rows` /
`_row_to_json` in `snpdb/variant_sample_information.py`. Rows are already scoped to samples the user can read, so
adding the path there doesn't widen what anyone can see.

### Client

`js/variant_sample_information.js` — a render function per row calling the existing
`open_igv_link(locus, bams)` (`js/grid.js:195`). Path prefix rewriting (`UserDataPrefix`) and the "is IGV running?"
error modal are already handled inside `create_igv_url` / `open_igv_link`.

`view_variant.html` already ships `window.ANALYSIS_SETTINGS.igv_data` (base_url, genome, replace_dict), so nothing new
is needed there. The section also loads inside the analysis variant details tabs, where `ANALYSIS_SETTINGS` comes from
the analysis window — `getAnalysisWindow()` handles that already.

### Gating

`createIgvUrl` returns null unless `ANALYSIS_SETTINGS.show_igv_links` is set, and the settings feature flag is
`get_settings_form_features().igv_links_enabled` (already passed to the page as `igv_links_enabled`,
`variantopedia/views.py:839`). Both should gate the column, on top of "some row has a BAM".

### Note

The link takes the locus from the row's own genome build — the grid can hold rows from several builds (an allele's
variants), and IGV is pointed at one `igv_genome` at a time (`igv_data['genome']` comes from the page's build).
Loading a BAM aligned to a different build than IGV's current genome is meaningless, so rows in other builds
should either be skipped or use that build's genome.

Start with _build_rows and _row_to_json in snpdb/variant_sample_information.py, then trace Sample.get_bam_files(), js/variant_sample_information.js, and open_igv_link in js/grid.js. Confirm the existing IGV feature gating and genome-build handling before adding the per-row behavior; done means only applicable BAM rows show working links and the column is omitted when none qualify.

Written by the indexing model from the issue text.