Relative Contact Registration

Barnekreftforeningen's peer mentors support entire family units around children with cancer - parents, siblings, and primary caregivers all need attention and follow-up. Without structured relative registration, these relationships exist only in unstructured notes, creating gaps in care delivery and making it impossible for coordinators to verify which family members have received support. This feature is explicitly a Phase 1 MUST-HAVE for Barnekreftforeningen, meaning the platform cannot serve this organization without it. It is foundational infrastructure for the entire Relatives Database module: case linking and role tagging both depend on relative records existing as proper first-class entities rather than free-text annotations on a contact record.

Relatives are stored in a dedicated relatives table sharing the same address and communication field schema as contacts. Riverpod providers manage relative state with Drift for offline-first persistence, following the same architecture as the contacts module. The RelativeRegistrationScreen presents a multi-field form with name, contact details, and a provisional relationship note. All form controls must meet WCAG 2.2 AA: semantic labels, 4.5:1 contrast ratio, and minimum 24px touch targets. The REST API validates organization membership before persisting a relative, enforcing tenant isolation. Offline mutations queue via the mutation outbox and sync with retry/backoff on reconnect. ID mapping handles offline-created relative IDs when the server assigns canonical IDs after sync.