Show patient phenotype in analysis node editors

Split out from #1561.

Several analysis source nodes wrap one or more samples whose patients carry free-text phenotype (`patients.Patient.phenotype`) and matched HPO/MONDO terms. Today this data isn't shown in the node editor, so analysts have to leave the analysis to inspect it.

We should surface the patient phenotype consistently across nodes that have one or more samples behind them:

- `SampleNode` — one sample
- `TrioNode` — mother/father/proband
- `QuadNode` — mother/father/proband/sibling
- `CohortNode` / `PedigreeNode` — N samples
- (any other source node that resolves to samples with patients)

### Behaviour

In the node editor, for each member sample:

- Show the patient's phenotype text (truncated with hover/expand for long entries).
- Where multiple members are present (Trio/Quad/Pedigree), visually flag when affected members' phenotypes differ — initial implementation: simple string-difference badge against the proband. A richer comparison (HPO term overlap) is a follow-up.

No filter behaviour changes — this is informational only. A phenotype-aware filter is a separate, larger design.

### Implementation direction

Rather than fattening every source-specific REST endpoint (`api_view_quad`, `api_view_trio`, etc.) with phenotype fields, add a shared endpoint that returns phenotype data for a set of samples — e.g. `GET /api/sample_phenotypes?sample_ids=…` returning `{sample_id: {phenotype, hpo_terms, …}}`. Each node editor can call it after loading the node's member list. Keeps phenotype concerns in one place and lets us evolve the payload (HPO terms, severity, …) without touching every serializer.

### Out of scope

- Phenotype-aware variant filtering.
- Phenotype display on the analysis graph itself (only the editor for now).
- Editing patient phenotype from the node editor.