Variant details - samples grid - sample membership (cohort/trio/pedigree) and trio inheritance

🤖 Written by Claude

Split out of #98 (*Variant details - samples grid - classifications, VCF filter, and other builds / inheritance*), where inheritance was raised in a follow-up comment:

> Also to have inheritance model - if patient is in a trio, then show how it was inherited

#98 covers multi-build samples, VCF FILTER and classifications in the variant details samples grid — all "attach more data to rows we already fetch". Inheritance and sample membership are a different feature with their own design questions, so they're tracked here to avoid holding up the rest.

## What this covers

### Sample membership

Show what each sample belongs to — cohort, trio (**and which role**: *father in trio Fam1*), pedigree.

This is useful in its own right, independent of any variant, and needs its own column/rendering design. It's also the natural home for the trio link, since a sample can be a member of several trios in several roles.

### Trio inheritance

For a sample that is a proband in a trio, show how the variant was inherited, based on the observed mother/father/proband genotypes.

## Design questions (why this isn't just one more column)

**Confirmed vs putative de novo.** Parents `HOM_REF` at a called site is a *confirmed* de novo. Parents `.` is only *putative* — the data cannot distinguish "absent" from "not looked at". These must render differently, or the grid will assert de novo status it cannot support. The same split applies to each "not inherited from this parent" branch.

**Which trios.** A sample can be proband in multiple trios, and can be a parent in one trio while being a proband in another. One grid row may carry several inheritance statements.

**Zygosity semantics.** Should reuse `AbstractTrioInheritance.NO_VARIANT` / `HAS_VARIANT` (`analysis/models/nodes/sources/trio_node.py:62`) rather than restating them, so the labels here agree with what the analysis TrioNode filters actually do.

Since `snpdb` must not import `analysis`, that means first moving those sets onto `Zygosity` (`patients/models_enums.py:25`, which already carries `ALL_ZYGOSITIES_SET` and `VARIANT`) and pointing `TrioNode` at them. Small refactor, but it touches the analysis app.

**Permissions.** Trio visibility (`Trio.filter_for_user`, via cohort) and parent *sample* visibility are separate checks. The grid must not assert a genotype for a sample the user cannot read.

## Data access — the easy part

Trio members are configuration over a cohort, and the locus walk in `VariantZygosityCounts` (`snpdb/variant_sample_information.py:18`) already decodes every sample of every VCF-backed `CohortGenotype`. So a `{sample_id: zygosity}` map built during that pass yields parent genotypes **with no extra queries**.

Note that a `Cohort` can be custom and span VCFs (`vcf` is nullable — `snpdb/models/models_cohort.py:53`), so trio members are not structurally guaranteed to share a single `CohortGenotype` row. This doesn't change the approach: each parent is found via its own VCF's row, and a parent whose VCF has no row at that locus is genuinely the no-call (putative) case.

Relevant models: `Trio` (`snpdb/models/models_cohort.py:767`), `Sample.get_genotype` (`snpdb/models/models_vcf.py:445`).

## Dependency on #98

#98 replaces the server-rendered jqGrid with a REST API feeding a client-side DataTables grid. Its row objects are a flat list, specifically so this work lands **additively** — a new `inheritance` / `membership` key per row, with no reshaping of the API contract.

Best done after #98, reusing that grid and payload.

Start with dependency #98 and its REST/DataTables row contract, then read snpdb/variant_sample_information.py, snpdb/models/models_cohort.py, snpdb/models/models_vcf.py, and analysis/models/nodes/sources/trio_node.py. Review how Trio permissions and genotype access work, then define the additive membership and inheritance row data with the stated confirmed-versus-putative and multi-trio distinctions; done means the grid exposes these details without reshaping the existing API.

Written by the indexing model from the issue text.