Hospitalizations & Surgeries — add/edit/delete list

Description

Significant past events: admissions and procedures. Repeatable-entry list.
Unlike #41 these are genuinely episodic, so date matters more — but the same
"approximate is fine" rule applies.

Fields — need confirming, not sourced from any ADR

• What happened (admission or procedure)
• Date (approximate acceptable)
• Hospital or facility
• Reason
• Notes

Whether hospitalizations and surgeries are one list with a type field or two
lists is the same question #37 faces. Answer it the same way, and say so.

Acceptance Criteria

• One-list-or-two decision made and recorded, consistent with whatever #37 chose
• Add, edit, delete against the encrypted local database
• Built on the #49 component
• Ships its migration
• Sorted most recent first if that reads better than the shared oldest-first default — if so, raise it as a change to the shared layer rather than sorting in the screen
• 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.
• The repository's default ordering is oldest-first with an id tiebreak, chosen for stable rendering. A history list is the most likely place that default is wrong

QA

• Add several events across different years, relaunch, confirm order and content
• VoiceOver/TalkBack through add, edit and delete

Start by reading the decision from #37 and the props contract for the #49 component. Use the in-memory SQLite harness to define the migration and unit tests, coordinating the migration id before implementing the add, edit, and delete flow. Done means the chosen list structure persists encrypted data, meets the accessibility and ordering requirements, and passes the listed QA checks.