Family History — add/edit/delete list

Description

Conditions that run in the family, recorded per relative. Repeatable-entry list.

This is the one Phase 1 list that holds information about someone other than
the patient, which is worth a moment's thought: a relative has not consented to
being in this journal. Nothing in the ADRs addresses it. Raise it rather than
resolving it in a hackathon PR.

Fields — need confirming, not sourced from any ADR

• Relative (relationship, e.g. "mother", "maternal grandfather")
• Condition
• Notes

Record the relationship rather than the relative's name — it is what is
clinically useful, and it keeps a third party's identity out of the journal.

Acceptance Criteria

• Add, edit, delete against the encrypted local database
• Built on the #49 component
• Ships its migration
• Relationship rather than name, unless someone decides otherwise on the record
• Field list confirmed before merge
• WCAG-aligned; copy neutral per 0004
• Covered by unit tests

Additional Info and Resources

• Not blocked on #118 finishing — only on its props contract. The repository
  config, the migration and their tests can be written first against the
  in-memory SQLite harness; the screen fills in behind once #118 publishes the
  component's shape.
• Coordinate your migration id before you start. assertWellFormed requires
  them contiguous from 1, so parallel PRs each adding "migration 1" all conflict
  after the first one merges. Renumbering an unmerged entry is fine — the "never
  edit a merged entry" rule only applies once it has shipped.
• Third-party data is unaddressed by 0006, which is about field categories rather than whose data they are. Worth an ADR of its own if anyone wants relatives' names

QA

• Add entries for several relatives, relaunch, confirm persistence
• VoiceOver/TalkBack through add, edit and delete

Start by reviewing the #49 component and the #118 props contract, then confirm the relationship and field decisions, including the unresolved third-party data policy. Use the in-memory SQLite harness and assertWellFormed while coordinating the migration id. Done means the encrypted database supports add, edit, delete, persistence, migration, unit tests, and VoiceOver/TalkBack QA.