V6.2 Add GEDCOM data

docs/architecture.md

@@ -121,6 +121,8 @@ Responsibilities:
 - `ExecutionAttempt` is append-only evidence for each provider call.
 - `Photo` is person imagery owned by `PhotosService`.
 - `MaintenanceRun` is one queued or executed operational maintenance run.
+- `GenealogyPerson`, `GenealogyFamily`, `GenealogyFamilyChild`, and `GenealogyCitation` store
+  imported GEDCOM genealogy data and citation provenance.
 - `DocumentType` and `PersonRole` are UUID-backed registries with optional protected `semantic_key`.
 - `Tag` is a shared registry reached through both document and person tagging, linked by
   `DocumentTag` and `PersonTag`.
@@ -147,7 +149,7 @@ Responsibilities:
 - **MaintenanceRun statuses:** `queued`, `processing`, `succeeded`, `failed`
   - Maintenance uses `succeeded` rather than `transcribed`; the transcription vocabulary does not
     apply to operational runs.
-- **Maintenance job types:** `backup`, `storage_reconciliation`
+- **Maintenance job types:** `backup`, `storage_reconciliation`, `gedcom_import`
 
 ## Maintenance Execution
 
@@ -157,7 +159,8 @@ lifetime and is recorded:
 1. Settings enqueues a `MaintenanceRun` with `status=queued` and a `triggered_by` marker.
 2. The worker claims the oldest queued run with a conditional update, moving it to `processing`.
 3. `backup` runs the deploy backup script; `storage_reconciliation` compares stored media against
-   `Document`/`Source` records.
+   `Document`/`Source` records; `gedcom_import` parses the latest uploaded `.ged` file and upserts
+   genealogy records.
 4. The run finalizes to `succeeded` or `failed` with summary, timing, log path, and `error_detail`.
 
 `MaintenanceRun` records operational history and is not evidence in the `ExecutionAttempt` sense;