MatchMaker Exchange from the patient page (phenotype + aggregated candidate genes)

🤖 Written by Claude

## Summary

MatchMaker Exchange (MME) outbound submissions are currently launched from a **Classification**, which gives us a curated allele + gene. This issue proposes also supporting MME from the **patient page**, where we typically know the phenotype but not a classified allele.

Related: MME integration #1662, Beacon #1661.

## Why this makes sense

MME is **patient-centric**, so the patient page is arguably its more natural home — the phenotypes (HPO) live on the patient, and our current classification-driven builder already reaches into the linked patient to pull them (`classification_ontology_slots()` part 2 in `mme/serializers/patient_profile.py`).

Crucially, **MME does not require an allele.** Per the v1.1 spec (and our own plan, `claude/matchmaker_exchange_plan.md:68`, `:375`) a profile needs *at least one* of:

- `features` (HPO phenotypes), or
- `genomicFeatures` — and a **gene alone is valid**, no variant needed.

So a patient with HPO terms (and ideally a candidate gene) is a valid MME query. Requiring an exact allele would actually be counterproductive — the point of MME is to find a patient with a *different* variant in the *same gene* + *similar phenotype*.

## Main piece of work: what genes does a patient have?

The genomic anchor is the open question. A gene-less, phenotype-only query is spec-valid but returns weak/noisy matches, so we want to derive candidate gene(s) for a patient.

Likely approach: aggregate genes across the patient's samples — e.g. `Sample.get_queryset()` for the patient, then aggregate genes from linked data (classifications on those samples, gene lists, etc.). Needs scoping:

- Where do candidate genes come from? (classifications on the patient's samples / associated gene lists / manual entry)
- How to aggregate + de-dupe across multiple samples
- How to let the curator pick which gene(s) to submit vs. submitting all

## Keep the existing safeguards

Whatever the launch point, preserve the deliberate curator checkpoint that classification-launched MME has:

- **Consent / share decision** — classification only submits `PUBLIC` records; the patient page has no equivalent gate yet, so we need one.
- **Contact for follow-up** — MME matches come back as an email to a human; the submission must carry a real contact.
- **Deliberate submit** (not an automatic fire-off from viewing a patient).

## Suggested acceptance criteria

- [ ] Decide the genomic-anchor source(s) for a patient and how to aggregate genes across their samples
- [ ] Patient-page MME launch builds a valid profile from patient phenotype + candidate gene(s), with no allele required
- [ ] Curator consent / share gate defined for patient-launched submissions
- [ ] Contact block resolved for a patient submission
- [ ] Phenotype-only (no gene) queries either warned about or handled explicitly

Start with mme/serializers/patient_profile.py, especially classification_ontology_slots(), then inspect Sample.get_queryset() and the referenced claude/matchmaker_exchange_plan.md sections. Define the patient gene aggregation and curator safeguards before implementing a deliberate patient-page launch; done means valid phenotype-plus-gene or explicitly handled phenotype-only submissions with consent and contact details.

Written by the indexing model from the issue text.